DECEMBER 198f 


MDC H1343A 



SPACE STATION DATA SYSTEM 
ANALYSIS/ARCHITECTURE STUDY 


Task 1 - Functional Requirements Definition, DR-5 




“ft 




H Mar >$86 

M 


(NASA-CR-177838) SPACE STATIOM DATA SXST 
ANALYSIS/ ARCHITECT ORE STUDY. TASK U 
FUNCTIONAL BBCDIBf HEMTS DEFINITION, DR 5 
{McDonnell- Douglas Astronau ics * ) cscL 2 | fi g3/1 8 
HC A14/MF AO 1 


N86-20473 

Unclas 

04590 




CORPOI74r/OW 


SPACE STATION DATA SYSTEM 
ANALYSIS/ARCHITECTURE STUDY 

Task 1 - Functional Requirements Definition, DR-5 


DECEMBER 1985 MDC H1343A 

REPLACES MDC HI 343 
DATED OCTOBER 1984 
REVISED MAY 1985 


NICDONNE LL DOUGLAS ASTRONAUTICS COMPANY- HUNTINGTON BEACH 

5301 Bolsa Avenue Huntington Beach, California 92647 (714) 896-331 1 



PREFACE 


The McDonnell Douglas Astronautics Company has been engaged In a Space 
Station Data System Analysis/Architecture Study for the National Aeronautics 
and Space Administration, Goddard Space Flight Center. This study, which 
emphasized a system engineering design for a complete, end-to-end data system, 
was divided Into six tasks: 


Task 

1 . 

Functional Requirements Definition 

Task 

2. 

Options Development 

Task 

3. 

Trade Studies 

Task 

4. 

System Definitions 

Task 

5. 

Program Plan 

Task 

6. 

Study Maintenance 


McDonnell Douglas was assisted by the Ford Aerospace and Communications 
Corporation, IBM Federal Systems Division and RCA In these Tasks. The Task 
inter-relationship and documentation flow are shown In Figure 1. 


This report was prepared for the National Aeronautics and Space 
Administration Goddard Space Flight Center under Contract No. NAS5-28082 


Questions regarding this report should be directed to: 

Glen P. Love 
Study Manager 

McDonnell Douglas Astronautics Company 
Huntington Beach, CA 92647 
(714) 896-2292 
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Section 1 
EXECUTIVE SUMMARY 


The initial task in the Space Station Oata System (SSOS) Analysis/Architecture 
Study is the definition of the functional and key performance requirements for 
the SSOS. The SSDS is the set of hardware and software, both on the ground 
and in space, that provides the basic data management services for Space 
Station customers and systems. The primary purpose of the requirements 
development activity is to provide a coordinated, documented requirements set 
as a basis for the system definition of the SSOS and for other subsequent 
study activities. These requirements should also prove useful to other Space 
Station activities in that they provide an indication of the scope of the 
information services and systems that will be needed in the Space Station 
program. Key objectives of the requirements development task are as follows: 

1. Identify a conceptual topology and architecture for the end-to-end 
Space Station Information Systems SSIS. 

2. Develop a complete set of functional requirements and design drivers 
for the SSIS. 

3. Develop functional requirements and key performance requirements for 
the Space Station Data System (SSDS). 

4. Define an operating concept for the Space Station Information Systems 
SSIS. 

The operating concept was developed both from a Space Station payload customer 
and operator perspective In order to allow a requirements practicality 
assessment. 
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1.1 METHODOLOGY 


The SSDS requirements task methodology emphasized the use of higher level 
requirements that were developed in other Space Station activities. The 
requirements methodology flow is shown In Figure 1-1. The primary sources of 
higher level requirements were; (1) the mission, operations, and system 
requirements from the Space Station definition and preliminary design RFP, (2) 
the Customer Requirements for Standard Services from the SSIS document 
prepared by GSFC, and (3) the Mission Requirements Working Group mission data 
base. In addition, other Space Station documents, requirements developed on 
other space programs, and industry study reports were used to identify 
potential requirements. It should be noted that the RFP and the customer 
requirements document were not available until late in the study task. The 
requirements imposed by these documents were superimposed on a basic set of 
requirements that had been developed earlier from the previous NASA studies, 
industry studies, and functional analysis. 



2 







To establish a context for defining and testing requirements, a concept for 
the SSOS, and for a more encompassing Space Station Information System (SSIS), 
was defined. The definition includes a description of the system topology, 
its architecture, and an operational concept. The SSIS "topology" is a 
description of the SSIS showing its elements and their interconnections, i.e., 
what the system looks like. The "architecture" describes the form of the 
system as viewed by the customer/user, i.e., how the system works. The 
operational concept describes scenarios for customer and system operator 
interaction with the SSIS. The concepts that have been defined provide a 
context for requirements generation and should not be taken as a 
representation of the final architecture of the SSDS. However, certain themes 
have been established in the concept that have been used to influence the 
requirements and will be carried into the system definition task. These 
themes include standardization of interfaces, elements, and procedures, an 
end-to-end view of the system, a continual emphasis on customer 
accommodations, and a cost versus benefit approach to autonomy and automation. 

Given the SSIS topology, and the higher level requirements contained in the 
RFP, the GSFC Customer Requirements for Standard Services document, and the 
mission requirements data base, a detailed set of SSIS and SSDS functions was 
identified and the associated requirements defined. A system analysis 
technique called Structured System Analysis (SSA) was used to decompose high 
level functions into lower level functions and to test the completeness of the 
function set. SSA creates data flow diagrams that describe the information 
flow and identify processes that affect information as it flows through the 
system. The top-level data flow diagrams for the SSDS are included in Section 
6.2. The functions list and the associated requirements are contained in 
Section 5 and in Appendix A. The operations concept was used as a cross check 
on the practicality, completeness and adequacy of the requirements. 

Functional requirements are presented in a hierarchical manner for clarity. 

For the lower level functional requirements, requirements data sheets were 
completed that defined, for that function, its meaning, criticality, 
interfaces, and key performance requirement(s) . This data is entered in a 
computer data base and is presented in Appendix A. 
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Traceability of the SSDS requirements has been developed to show both 
"top-down" and "bottom-up" traceability. The top-down traceability shows, for 
each applicable requirement in the higher level documents, what SSOS function 
defines and Implements the corresponding SSDS requirement. Bottom-up 
traceability defines, for each SSOS requirement that we defined, what its 
higher level source(s) is. 

1.2 SSIS/SSDS CONCEPTS 

A model was established for the SSIS in the form of a topology of the 
end-to-end information system for Space Station customer and operators, 
encompassing both space and ground elements. The space elements in the SSIS 
were defined to Include the Space Station (base), the platforms, OMV, OTV, and 
co-orbiting free-flyers. Ground elements were identified to operate the 
system and support the major end-to-end functions. These elements (or 
functions) Include Space Station control, platform control, OHV control, OTV 
control, data handling, and customer data centers (regional data centers and 
customer remote facilities). Added to this were data distribution elements 
and support elements to complete the end-to-end nature of the SSIS. Primary 
information interfaces were Identified to complete the functional topology. 

The SSDS is defined as a subset of the SSIS. A set of criteria was defined to 
determine the placement of SSIS elements Inside or outside the SSOS. The 
Intent of the criteria was to refine the study statement of work definition of 
SSIS/SSDS boundaries, including consideration of NASA funding and 
organizational patterns, and to exclude unique customer applications and core 
systems functions from the SSDS. These SSIS/SSDS boundary definitions apply 
to both space and ground functions. The primary criteria used were (1) the 
perception of the SSIS element or function, as a user standard service, and (2) 
the perception of the element or function as a core service. In general, 
elements or functions that met either of these criteria were placed in the 
SSDS. Figure 1-2 shows the SSIS/SSDS model resulting from the use of the 
boundary criteria. A more detailed discussion of the criteria and the 
SSDS/SSIS division is contained in Section 4. 
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Figure 1-2. SSIS/SSDS Model 


A key interface for the SSDS is with the planned Space Station Technical and 
Management Information System (TMIS). While the TMIS fits at least partially 
within our concept of the SSIS, we have defined the SSOS to be mutually 
exclusive of the TMIS. The TMIS Is expected to be the primary repository of 
Space Station program management and engineering data, and certain types of 
operational data. SSDS functions use and access the TMIS data bases and, in 
turn, provide data to the TMIS. Onboard crew, mission controller, and 
customer access to the TMIS data bases may be provided through the SSIS. 

The architecture concept for the SSIS is an explanation of how the SSIS works 
in moving, processing, and storing data. The architecture description 
provides a top level view of how the system manages commands, manages customer 
and operator data, supports system scheduling and control, manages core 
systems and resources, supports simulation, integration, and training, and 
provides (limited) programmatic support. This top-level "how-1 t-works" 
description gives an Integrated overview of the major SSDS functions. 
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A concept of command management was developed that provides validation, 
conflict checking to avoid undesirable payload Interaction, and feedback to 
ensure system integrity and safety while providing a high degree of autonomy 
to the customer. In fact, customers should be unaware of the command 
management process unless a real conflict is detected which precludes or 
delays the execution of a command. 

A more detailed view of the SSIS is provided In the discussion of operational 
concepts, which is provided both from customer and operator perspectives. The 
operations concept provides a view of the primary customer Information system 
needs and an operational approach that Is responsive to those needs. These 
needs encompass system transparency, customer operational autonomy, data 
integrity, system friendliness, and flexibility. An SSIS which has these 
attributes can contribute greatly to the ability of the customer to maximize 
return on his space mission Investment. The SSIS must also support the 
overall program needs for crew safety, system Integrity, and overall system 
management, including a capability to resolve competing demands for system 
resources. The operations concept described in Section 4 addresses these 
customer and system needs for information services. A key feature of the 
operations concept from the customer's perspective is the plan to allow a 
customer to Interact with the SSIS on his terms to the maximum extent 
feasible. In other words, the customer can interact using nonspecialized 
hardware and software, with minimal specialized training, from a location and 
at a time of his choosing, and with minimal operational constraints. 

The operator's perspective of SSIS operations describes a view of how onboard 
crew members, ground controllers, planners, and system developers Interact 
with the SSIS, and how the SSIS supports their operations. 

Autonomy and automation are important top-level themes that Influenced our 
operations concept. Autonomy and automation are Intended to improve cost 
effectiveness, crew productivity, system performance, and reliability. These 
techniques will be applied to our future architecture definition where they 
produce clear advantages. 
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The SSIS provides resources to support long- and short-term planning and 
scheduling. The THIS provides supporting analyses and data bases in the area 
of mission manifests and accommodation analysis. The short-term functions 
will be shared between the space and ground elements with a capability to do 
the daily activity scheduling and rescheduling onboard the station. As the 
system matures, a higher percentage of the planning and scheduling activity 
will be performed on board. 

The Importance of standardization to the operating and architectural concepts 
Is apparent. The multiplicity and complexity of customer needs could drive 
system costs and customer costs out of reasonable bounds if a standards 
discipline is not Imposed on the system. Selection of appropriate standards 
can significantly help control system and customer costs for development, 
integration, training, operations, and maintenance. Our theme for selecting 
standards will be to use widely accepted commercial and international 
standards In areas where they are available and to recommend the use of new or 
evolving standards In other areas. 

1.3 SSIS/SSDS FUNCTIONAL AND PERFORMANCE REQUIREMENTS 

The key functional requirements for the broadly defined SSIS have been defined 
and an assumed allocation made to Space Station Program Elements (SSPEs). 
Drivers on the SSDS related to these requirements are Identified. Functional 
requirements for the SSDS were defined at a greater level of detail and key 
SSDS performance drivers were Identified. A traceability matrix was developed 
to show the source of SSDS requirements In higher level documents and to show 
the allocation of higher level requirements to SSDS functions. 

The functional requirements allocated to the SSPEs, that are not in the SSDS, 
are complementary to the functions assigned to the SSDS. The Identification 
of these requirements provides an indication of the functional interfaces 
between the SSDS and other program elements. The SSDS drivers that have been 
identified are primarily related to (1) data rates, and (2) activity 
scheduling. Mission aggregate data rates are clearly going to be a major 
Influence on the SSOS system design, affecting onboard acquisition and 
storage, onboard communication processing, TDRSS utilization, ground data 
distribution, ground data processing, and data archiving provisions. 
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The complexity and simultaneous nature of mission tasks and the need to 
consider several interrelated resource constraints will make activity 
scheduling a challenge. SSOS provisions to support the activity scheduling 
will be driven by these considerations. 

Several customer standard services have been identified and have been 
allocated to the SSIS (external to the SSDS). This allocation was made on the 
basis that, (1) it was determined that the service will most likely be 
implemented as a multiprogram (institutional) NASA service, i.e., not 
dedicated to the Space Station program, or (2) it was determined that the 
service should be offered as a customer option (extended service) because it 
may not be universally needed. These customer services Include ground 
processing of customer data beyond GSFC-defined Level 0 (time-ordered raw 
data, separated by customer, with essential ancillary data), long-term data 
archiving, customer-to-customer data exchange, customer facility work 
stations, and certain long-term planning and programmatic data that is assumed 
to be in the THIS. 

The SSOS functional requirements are organized into a hierarchical set of 
functions under seven top-level functions as shown In Figure 1-3. This 
organization of functions is carried down to the third and fourth levels in 
the SSOS functions list and is consistent with our data flow diagrams. 

Function 1.0, Manage Customer/Operator Delivered Data , contains those 
requirements related to payload and core data acquisition, time-tagging, 
distribution, buffering, temporary storage, and display. Including the 
processing necessary to support these activities. Data accounting 
requirements are Included. Requirements for real-time and delayable data for 
customers are addressed. Level 0 data processing Is available as a standard 
customer service. 

Function 2.0, Manage Customer/Operator Supplied Data , encompasses the 
requirements associated with commands and other data that originate at the 
customer or operator. These Include command distribution and validation, and 
ancillary data acquisition, formatting, and distribution. Also Included are 
customer support requirements related to payload pointing, payload control 
processing, payload monitoring, and quick-look data processing. OTV, OMV, and 

payload checkout operation support requirements are defined. 
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NOTE: Requirements listed at a higher level are generally applicable to all lower level functions. 



Function 3.0, Schedule and Execute Operations , contains those functional 
requirements related to developing generic and specific schedules, command 
conflict checking, and the control of command sequences. Specific scheduling 
products have been identified, including a typical day schedule, a short-term 
schedule, and an operating event schedule. 

Function 4.0, Operate Core Systems , contains the SSDS requirements which have 
been collected to support core system operations, to provide crew support in 
areas such as health maintenance, recreation, EVA, training, and safety, to 
provide special onboard customer services, and to monitor both core and 
customer systems. The special customer services include: monitoring of 

contamination, venting, and the general payload environment; providing 
relative alignment reference; providing current and projected ground track 
information; and providing current and projected magnetic field information. 
The system monitor and status functional requirements Include caution and 
warning and mass properties status. 

Function 5.0, Manage Facilities and Resources , contains the SSOS functional 
requirements for managing space and ground data processing facilities of the 
Space Station Program. The ground facilities include control centers, data 
handling facilities, and support facilities. As part of this functional area 
the SSDS is required to monitor customer usage of Space Station resources for 
potential billing purposes. This function also includes SSDS requirements to 
reconfigure facilities in response to operations or maintenance timelines or 
system failures. 

Function 6.0, Develop. Simulate. Integrate, and Train , contains the SSDS 
functional requirements to support development, simulation, integration, and 
training. This very broad set of requirements are Interrelated in their 
extensive use of simulation models. They are also related in that they are 
primarily off-line from the mission operations. These requirements are 
intended to meet the majority of core system and customer needs for Integrated 
system simulations. 

Function 7.0, Support Space Station Program , includes SSDS requirements for 
support of programmatic activities such as logistic planning, operating manual 
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maintenance, inventory control, and configuration management. The SSDS will 
be closely coupled to the Technical and Management Information System (TMIS) 
in this functional area. The exact allocation of functions between the SSDS 
and the TMIS will need to be refined as the two systems become better defined. 

In reviewing the SSOS requirements that have been defined, several areas 
appear to contain the most critical drivers to the SSDS design. These areas 
are related to (1) overall data rates, (2) real-time payload operation, (3) 
automation and autonomy, (4) development, training, and simulation support, 5) 
level of physical distribution, and (6) scheduling. In these areas, the 
magnitude or complexity suggested by the requirements Indicate that particular 
attention should be paid to these areas in future study tasks. 

1.4 CONCLUSIONS ANO RECOMMENDATIONS 

An overall concept has been defined for an end-to-end SSIS that includes all 
major SSIS elements and functions. The concept, and the accompanying 
operational concept for the SSIS, served as a context for validating the 
completeness and correctness of the set of functional requirements. 

Within the SSIS, the SSDS was defined by developing a set of boundary 
criteria. The functional requirements for the SSDS were developed in detail 
by identifying requirements In higher level documents, decomposing the 
requirements through functional analysis, and allocating the requirements to 
SSDS by use of the boundary criteria. This set of functional requirements are 
soundly derived and are adequate to support the subsequent tasks of the study. 

Key performance requirements were derived from the higher level source 
requirements. SSDS design drivers have been identified in the requirements 
set and can be used to properly focus the trade studies and system definition 
activities. 

Recommendations resulting from this task are as follows: 

1. The operating and architectural concepts developed in this task 
should be presented to Space Station operators and potential 
customers for comment and feedback. 





2. The Mission Requirements Working Group data base should be refined 
and expanded to provide more definitive customer requirements in 
areas such as live television, remote real-time operations, ancillary 
data type and quality, and data delivery. 

3. A special emphasis study should be conducted to define customer 
classes and a NASA interface scenario with the classes. 

Results from these activities will enable requirements refinement and SSIS 
operating concepts completeness. 
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Section 2 

TASK 1 DESCRIPTION 

The MDAC Team has completed the Functional Requirements Definition (Task 1) 
for the Space Station Information System (SSIS) design. The major products of 
Task 1 are: 

1. Top level end-to-end SSIS overall concept, including: 

a. SSIS operational concept from both customer and operator 
perspectives 

b. Functional topology 

c. Functional architecture 

2. SSIS functional requirements 

3. SSDS Interface definition 

4. SSDS functions identification 

5. SSDS functional requirements 

6. SSDS requirements drivers 

7. Computer-based requirements traceability matrix 

In addition, a relational data base has been created which Includes design 
characteristics of the functions, and will be extended during the remainder of 
the study to Include function assignment to end item and physical location. 
This data base is reported In a separate document entitled "SSDS Functional 
Requirements and Oesign Characteristics". An example of the data contained in 
this document is shown in Figure 2.1. The electronic data base contains the 
output in four screens. These screens are merged Into two pages in the 
report. One page presents requirements and the other characteristics. 

2.1 PURPOSE 

Task 1 has been conducted to develop a top level, end-to-end SSIS overall 
concept and to provide a coordinated, documented set of requirements to serve 
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Figure 2-1. Function Data Base Presentation Format 








as a basis for the development of the Space Station Data System (SSOS) 
preliminary design. Results are documented in this report, principally in 
Sections 4 and 5 and Appendix A. 

2.2 SCOPE 

This report presents the results of Task 1 - Functional Requirements 
Definition, including: 

• The SSIS Functional Topology (Section 4.2) - Topology is defined as 
the structure and interrelationship of the subsections of the SSIS. 
The topology discussion identifies the physical elements comprising 
the SSIS and how they interconnect. The role of each element is 
defined, and top level functions are Identified. 

• The SSIS Functional Architecture (Section 4.3) - Architecture 
describes the functional form of the SSIS as viewed by the customers 
and operators. The architecture shows how the SSIS works. The 
architecture from Task 1 is preliminary and was developed to provide 
a basis for further system analysis. Details of the architecture are 
to be developed In Task 4. 

• The SSIS Operating Concepts (Section 4.4) - The operating concepts 
supplement the architecture by describing how the customers and 
operators use the system. 

• Functional Requirements (Section 5) - The SSIS and SSDS functional 
requirements define, by SSIS element and SSDS function, what must be 
done to meet the Space Station requirements (Reference 1), the 
customer requirements- for standard services (Reference 2), mission 
requirements compiled by the Mission Requirements Working Group 
(Reference 3), and the requirements Implied by the topology, 
architecture, and operating concepts. 

• SSDS Requirements Drivers (Section 5.4) Identifies those functional 
and performance drivers that are expected to have a major impact on 
the SSDS designs. 
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• The Requirements Traceability Matrix (Section 5.5) provides sources 
for all functional requirements and top-down traceability of all 
Space Station and customer requirements to responsive functions. 

This allows functions to be related to system requirements, 
establishing the scope of the functional requirements. 

• The complete functions list (Appendix A-4) and functional data sheets 
(Reference 14) characterize the functions and define key design and 
performance characteristics. 

• The functions list (Appendix A-4) contains indications of functions 
solely in the Space Station and its associated ground elements, 
common to both Space Station and platform systems, and replicated 
among the Space Station, platforms, and associated ground elements. 
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Section 3 
STUDY METHODOLOGY 


The Task 1 study methodology Is illustrated by the diagram of Figure 3-1. 
There are three principal sources of SSIS requirements Indicated: 


• The Space Station Phase B RFP Statement of Work, Attachments C-2, 
C-3, and C-4 (Reference 1) - The final draft, issued September 15, 
1984, was used to indicate the Space Station Program (SSP) scope and 
Space Station mission, operation, and system requirements. 

• The Customer Requirements for Standard Services from the SSIS 
(Reference 2) - Revision >, dated September 19, 1984, was used to 
indicate customer requirements for the SSIS. 



Figure 3-1. Requirements Definition Methodology 
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• Space Station Program Mission Requirements (Reference 3) - The 
Mission Requirements Working Group (MRWG) compilation of mission 
requirements, dated March 15, 1984, was used to indicate typical 
mission support requirements and key performance requirements to 
meet mission demands. 

The explicit and Implicit SSIS functional requirements from these documents 
have been combined with requirements resulting from the Task 1 analyses to 
form functional requirements (Section 5.2). The development of these 
requirements was facilitated by two principal analyses: 

• The development of a top level, end-to-end SSIS concept. Including 
topology, architecture, and operation. 

• Structured system analysis, identifying the logical functions of the 
system and their interrelationship (Section 6.2). 


The next step was to develop SSOS functional requirements (Section 5.3). 
Development of a complete set of performance requirements and an SSOS 
specification was deemed to be a part of the Task 3 and 4 effort. However, 
much of the groundwork for the SSDS specifications was laid in Task 1. 
Specifically, the team has 

1. Developed a complete list of SSDS functions which meet the 
functional requirements of the SSIS and References 1, 2, and 3. 

2. Performed complete Level 1 and limited Level 2 and 3 structured 
systems analyses to define and scope these functions. 

3. Mapped requirements from references 1, 2, and 3 to the functions 
list and developed a complete traceability matrix showing this 
mapping. 

4. Developed functional and key performance requirements for each 
function at the appropriate level from References 1, 2, and 3, 
other NASA documents, and the team data base. 
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5. Identified additional source documents supporting the need for 
and requirements on each function. 

6. Performed engineering analyses of mission requirements to derive 
key SSDS performance requirements. 

The results of these analyses are collected in the data base In Appendix A and 
Reference 14. The complete data base is available In the VAX computer at MDAC 
Huntington Beach In the Smartstar data management system. In Smartstar, the 
data base can be updated, supplemented by performance and design data from 
Tasks 3 and 4, manipulated to generate key parameter reports, and accessed by 
NASA and team members. 

The above work was greatly aided by prior and concurrent studies conducted or 
sponsored by the NASA. Table 3-1 shows some of the more frequently used 
documents and the portions of the Task 1 activity to which they were most 
applicable. The scope and depth of this prior work helps assure the 
completeness and correctness of the Task 1 products. 


Table 3-1. Prinicipal Documents Used in Task 1 


Document 

Usage 1 

Reference 

Developing 

SSIS 

concept 


SSIS 

requirements 

SSIS/SSDS 

functions 

Traceability 

matrix 

SSDS 

functional 

requirements 

SSDS 

performance 

requirements 

Space station RFP 

1 

V 


v • 

. V 

V 

V 

V 

Customer requirements 

2 

V 


V 

V 

V 

V 

V 

for standard services 









Mission requirements 

3 

n/ 

V 



V 

V 

V 

SSDS RFP 

5 

V 

• 


V 




Yellow book 3, 6 

6 

V 

V 


V 



V 

JSC 18740 

7 

V 

V 


V 




GSFC data system concepts 

8 

V 

V 


V 




JPLD1737 

KE 

V 

V 


V 




Space telescope 


V 




V 



Global positioning system 


V 



V 


V 

V 

TDRSS 


V 



V 


V 

V 

EOS status review 








V 
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Section 4 

SSIS/SSOS CONCEPTS 

A top level, end-to-end SSIS overall concept was developed in Task 1. This 
concept is described from five perspectives: 

1) Functional topology (what the system looks like) 

2) Functional architecture (how the system works) 

3) Operations from customer perspective 

4) Operations from a system operator perspective. 

5) Operations from buildup and growth perspectives. 

Each of these concept descriptions emphasizes the complete, end-to-end data 
flow. Identification of all of these data flows and all of the interactions 
customers and operators will have with the system ensures adequate breadth for 
the requirements. Decomposition of functional requirements can then be 
performed with confidence in the completeness of the scope. 

4.1 SSIS CONCEPT ASSUMPTIONS 

The key assumptions that guided the development of the SSIS concept are 
discussed below. 

4.1.1 Controlling Documents 

References 1, 2, and 3 were selected as controlling the scope, function, 
performance, and design of the SSIS and SSDS. 

4.1.2 Customer Service Assumptions 

Customers include all authorized users of Space Station program, engineering 
and payload data or products for scientific, commercial, or technological 
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purpose. Potential Space Station customer operating requirements affecting 
customer service functions of the SSIS include: 

• Customers will want to access SSIS services from onboard the Space 
Station or any of several ground locations, including the customer's 
own facility and facilities provided by the program and NASA. 

• Customers will want to operate their payloads interactively in real 
time. This operation may include coordination between onboard and 
ground operations. 

• Customers will want to choose from a variety of data return means to 
satisfy operational and economic constraints. 

• Customers will require quick-look payload data to ensure proper 
payload functioning. 

• Customers will desire interactive involvement in system schedule 
development, including real-time adjustments to accommodate targets 
of opportunity. 

• Customers will require system support throughout the phases of their 
programs from inception through development integration, activation, 
operation, and closeout. 

• Customers will have a variety of technical backgrounds. The system 
must be user friendly in order to accommodate all customers. It must 
facilitate their use of the system, minimize the need for special 
training, and maximize Space Station program productivity. 

4.1.3 Program Operating Assumptions 

The Space Station Program includes multiple ground and orbital elements 
operating together. Key operating assumptions affecting the function of the 
SSIS include: 

• The Space Station navigates using GPS. TDRSS provides backup 
navigation. 
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• Space and ground elements communicate primarily through the Tracking 
and Data Relay Satellite System (TDRSS). One, two or three Ku-band 
Single Access (KSA) and S-band Single Access (SSA) channels must be 
shared at least among Space Station Program Elements (SSPEs). A Task 
3 trade study will examine these alternatives. 

• The Space Station is normally operated onboard, with capability for 
at least limited operation from the ground. 

• The Space Station will provide data relay and navigation and control 
services for constellation elements. 

• The ground system will handle data for all SSPEs. 

• The system will support SSPE growth, expansion, and upgrade. 

4.1.4 Program Phase Assumptions 

The Space Station Program requirements on the SSIS will vary during the 
program phases. The following assumptions characterize the relationship 
during the development, buildup, and growth phases: 

• Development - The SSIS/SSDS will be developed in parallel with the 
modules, subsystems, ground facilities, and space elements. Portions 
of the SSIS may be available to support SSPE prelaunch verification, 
but the complete SSIS will not be operational until IOC. Simulation 
and integration test software and hardware developed for the 
integration tasks are assumed to be useable in the ongoing "Develop, 
Simulate, Integrate, and Train" function, especially the Software 
Support Environment (SSE). 

• Buildup - The SSIS capability to support remote operation of the 
Space Station and platforms must be in place at the beginning of the 
buildup phase. The initial Space Station module(s) transported to 
orbit is assumed to be unable to support continuous occupancy. The 
start of continuous operation will follow an on orbit integrated 
system test. IOC and continuous occupation are assumed to be 
coincident. 
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• Operation - The SSIS will fully support the continuing operation of 
the Space Station Program (SSP). The SSOS will support operation of 
the Space Station and its ground facilities, and coordinate 
multiprogram support services. The SSOS will support customer 
payload command and operation and deliver customer payload data. The 
SSIS will provide additional Standard Customer Services in support of 
customers throughout their involvement with the SSP. 

e Growth and Evolution - The SSIS will fully support the growth and 
evolution of the program and its associated elements. Growth and 
evolution includes adding new Space Station modules, adding new 
SSPE's, automating functions, relocating functions, expanding 
services, and improving system operation. The SSIS will support the 
development and verification of hardware and software to achieve 
growth and evolution, in addition to supporting operation of the 
system. 

4.2 FUNCTIONAL TOPOLOGY OF THE SSIS 

The functional topology of the SSIS shows the functional elements of the SSIS 
and their relationship. The topology was developed by first identifying the 
SSPEs, determining their roles, and identifying relationships. This 
functional topology represents a baseline to be used to develop SSDS 
requirements. Allocation of specific functions to systems, subsystems and 
facilities will be developed in Tasks 3 and 4. 

4.2.1 SSPE Identification 

SSPEs were identified from References 1 and 2, the assumptions of Section 4.1, 
other prior Space Station and Data System Studies, and system analyses of the 
SSIS. Table 4-1 shows the SSPEs identified and their sources. The SSPEs and 
roles thus identified provide a context for the SSIS. These SSPEs are used to 
develop the SSIS topology and their roles are used to aid definition of the 
SSDS element functions. 
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Space station 

Table 4-1. Space Station Program Elements, Sources, and Roles 
Paragraph 

program element 

Sources 

number 

Roles 

GPS 

RFP 1 

RFP 

C-4- 2.2.5.3f 

C-4- 2.2.6.2k 

Stable time and frequency reference 
Navigation signals 

Polar platform (POP) 

RFP 

C-2- 2.3 

Base for multiple payloads 

POP control 

RFP 

C-3- 2.4g 

Routine platform planning and operations 

Coorbiting platforms (COP) 

RFP 

C-2- 2.2 

Base for multiple payloads 

COP control 

RFP 

C-3- 2.4g 

Routine platform planning and operations 

Free fliers 

RFP 

B- 2 .1 2d 

SSPE’s 

Free flier control 

Analogy to RFP 

C-3- 2.4g 

Routine free flier planning and operations 

Space station 

RFP 

RFP 

RFP 

CRSS 2 

C-2- 2.1 

C-4- 1 .2 

C-3* 2.1c 

6.1.2 2 

Base for multiple payloads 
Laboratory and crew habitation provisions 
Service/ maintain OMV 
Operate customer payloads 

Space station control 

RFP 

RFP 

C-3- 2.4g 

C-3- 2.4j 

Coordinate SSP operations, planning and support 
Provide essential ground operations capability to 
space station 

TDRSS 

RFP 

CRSS 

C-4- 2.2. 6 .2g 

0.1 

Space station - ground communications 
Platform - ground communications 

Network control 

CRSS 

0.1 

Coordinate uplink/downlink service requests 

Data distribution network 

CRSS 

2 .2.3.4, 
3.1 .2.1 

Provide transparent data link between customer 
and onboard equipment 

Data handling center 

Engineering 

Analysis 

N/A 

Required to separate/ merge and buffer customer and 
core data steams 

OMV 

RFP 

C-3-l.lc 

Orbit maneuvers for satellite/platform servicing 

OMV control 

RFP 

C-3-2.4g 

Onboard and ground locations are required to control 
OMV operations 

OTV 

RFP 

C -3-2.1 d 

High energy orbit payload transfer 

OTV control 

RFP 

C-3-2.4g 

Ground location is prepared to control high energy orbit 
injection and return 

Space station payloads 

RFP 

C-2 -2.1 

Perform science and applications, commercial and technology 
Development missions 

Customer, subcontractor 

RFP 

C-3-2.4g 

Routine payload planning and operations 

Discipline data centers 

CRSS 

CRSS 

3.3.2 

3.4 

Routine customer data processing 
Maintain customer data archives 

Remote customer facilities 

CRSS 

6.1.2 

Command customer payload operation and data handling 

Space station engineering 

RFP 

C-4 -2 .2 .5.3e 

Archival storage of core system data 

data center 

CRSS 

4.1.1 

Provide stored and processed data to customers 

NSTS orbit er 

RFP 

RFP 

B-2.12a 
C -3-2.1 f 

Primary means for launch, access and resupply 
Tend initial and growth space station 

NSTS mission control 

CRSS 

0.1, 7.1 .2 

Long term rendezvous service planning, support 

Deep space network 

RFP 

C4-2.2 .6.2g 

Provide contingency command and telemetry link 

Launch integration site 

RFP 

C-3-2.3a 

Provide launch readiness verification 

Contractor facilities 

Engineering 

analysis 

N A 

Provide pre-delivery verification and integration test 

Development, simulation 

RFP 

C-3 -2 .3b 

Use flight system to reduce GSE for testing 

and training 

RFP 

RFP 

CRSS 

' C-3-2.3d 

C-3-2.5 

1.1.4 

Insure modifications and upgrades interface and 
function correctly 

Provide ground and onboard crew training 
Provide focal point for customer payload integration 
and test 

Other communications links 

RFP 

CRSS 

C -4-2.2 .6.2f 
U.10 

Provide customer payload-ground communication 
independent of TDRS/TDAS 

Technical management 
information system 

RFP 

C-6 

Provide program management services 

Provide SSP, engineering, operations, administrative 

and descriptive information 

EVA (MMU, EMU) 

RFP 

C-4-2.2.11 

Bill customer for services rendered 


Assembly, maintenance, servicing, repair of SS, 

1) Space station definition and preliminary design, RFP, September 15, 1984. platforms, structures, satellites, and vehicles 

2) Customer Requirements for Standard Services from the SSIS, revision 1, September 19, 1984 


25 



4.2.2 


Space Station System Element Connection 


ORIGINAL PACzS §$ 

OF POOR QUALITY 


The SSPEs and their interconnection are shown in Figure 4-1. The SSPEs are 
derived from those of Table 4-1. Their relationships to the SSIS are 
discussed below: 


• Global Positioning System (GPS) - The GPS is a system of satellites 
emitting signals which allow accurate determination of position and 
velocity. The Space Station, platforms, free-flyers, and the OMV and 
OTV are presumed to be able to navigate using GPS. GPS also provides 
an accurate time and frequency reference. 



Figure 4-1. Space Station Program Element Interconnection 


• Polar Platform (POP) and Control - The POP is a polar platform in 
sun-synchronous orbit which will be used primarily for earth and 
atmospheric observation. POP has no direct orbital communication 
with the Space Station, but will coordinate some observations and 
share some ground data handling facilities. Both will relay data to 
the ground through TORSS KSA channels. Since the Space Station and 
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POP need not transmit simultaneously, a single ground Data Handling 
Center and network sized to handle 300 Mbps could distribute data for 
both systems. The POP will be joined by other satellites which may 
similarly share the ground Data Handling Center. POP and these 
additional satellites will be controlled from their own ground 
control centers. 

e Co-orbiting Platform (COP) and Control - The COP is a platform in low 
inclination, low earth orbit. Early payloads are primarily 
astronomical and solar observatories. Other platforms, providing 
bases for multiple payloads, may be added. When in line of sight, 
the platform(s) may use the Space Station to relay data to and from 
ground stations and customer facilities. The Space Station provides 
tracking, traffic control, and support services. It may also provide 
remote platform and/or payload operation. Platforms at different 
orbital altitudes will not be able to maintain line-of-sight 
communications to the Space Station. These platforms must provide 
their own communication links, but may use Space Station ground 
facilities in the same manner as the POP. 

• Free-Flyers and Control - Free-Flyers are single payload satellites. 
When in orbits accessable from the Space Station, Free-Flyers may be 
serviced and maintained from the Space Station. The Space Station 
will provide communications, tracking, traffic control and support 
services to coorbiting free-flyers, including spacecraft and payload 
control options. 

e Space Station and Control - The Space Station is the permanently 
manned vehicle which provides a base for multiple payloads, 
habitation for the crew, and operating control for payloads, the 
Space Station, and constellation elements. The Space Station 
receives data from the payloads and constellation elements, and 
relays the data to the ground, together with core systems data, 
through TORSS. Customer payload commands and data, together with 
ground operator commands and data are relayed to the Space Station 
through TDRSS. The Space Station routes the commands and data to 
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payloads, core systems, and constellation elements. The Space 
Station must support real-time transmission of operating data and 
commands, near real-time transmission of quick-look data, and delayed 
transmission of bulk commands and data. Real-time operations of the 
payloads require limited two-way data relay, including audio and 
video links. Oelayed data will be packetized and transferred at 
rates consistent with the TDRSS KSA band. In addition, the Space 
Station must support onboard operation of the Station, its payloads, 
constellation elements, the OMV, and the OTV. The Space Station 
operation and control is supported from the Space Station Control 
Center. 

• Space Station's System Control - The Space Station System Control 
Center provides overall SSP coordination, including services such as 
scheduling and resource planning, coordination among SSPES, ground 
facilities management, portions of command management, and customer 
information coordination and dissemination. Their service will be 
defined during Task 4. 

• Tracking and Data Relay Satellite System (TDRSS), Network, and 
Control - The TDRSS satellites will be the primary means for 
communication between the Space Station and the ground. TDRSS 
provides Ku and S-band single access channels (KSA and SSA) and 
multiple access (MA) S-band channels for communication. The 
equivalent of one KSA will be available to the program for bulk data 
uplink and downlink. The equivalent of one SSA channel will be 
available for command and monitoring. An MA channel will be 
available for voice communication. The Tracking and Data Acquisition 
Satellite (TDAS), as a growth capability, will provide multiple beam 
antennas. This capability will allow direct data relay to multiple 
customer and SSOS centers, or even remote customer facilities. The 
TDRSS ground station at White Sands, New Mexico is a relay station. 

It provides for channel separation and retransmission through DOMSAT 
and other satellite and ground links. It is assumed that the 
aggregate of these links, comprising the Space Station Data 
Distribution Network, will be able to handle simultaneous KSA and SSA 
transmissions at the full TDRSS bandwidth capability. The Network 
Control Center regulates and allocates network operation. 
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• Data Handling Center - The Data Handling Center receives, buffers, 
and retransmits uplink and downlink data. Data from TDRSS are 
captured and pre-processed (if desired by the customer), separated 
according to destination, and retransmitted according to negotiated 
schedules. The records are purged when satisfactory receipt at the 
destination is confirmed. Uplink data are received, buffered, 
merged, and transmitted to TDRSS according to a negotiated schedule. 
Again, recorded data are purged when satisfactory transmission is 
conf i rmed. 

• Orbital Maneuvering Vehicle (OMV) and Control - The OMV provides for 
the deployment and retrieval of payloads in low inclination, low 
earth orbit. The vehicle is reusable and based on the Space 
Station. OMV will have manipulators and grapplers which allow it to 
retrieve and service satellites on orbit. The Space Station provides 
maintenance, resupply, and primary control. The OMV has a video 
camera which provides an image of the work to the operator for 
interactive control. The operator may be located on the ground for 
operations out of direct Space Station-OMV communications. The OMV 
will also be used to maneuver traffic through the constellation. 

• Orbit Transfer Vehicle (OTV) and Control - A reuseable OTV, or ROTV, 
is classified as a Space Station growth element. There may be 
interim, expendable stage OTVs as well. Both reuseable and 
non-reuseable vehicles will be referred to as OTVs in this report. 

The OTV is used to launch payloads to geostationary and other high 
energy orbits and return or to launch interplanetary missions. It is 
also possible that OTVs will be used to place or service payloads in 
intermediate Inclination orbits, in the absence of suitable National 
Space Transportation System (NSTS) flights. Payloads in 
geostationary orbit may also be serviced on orbit, using the robotics 
of an OMV. The OTV is based on the Space Station for maintenance, 
payload mating, and resupply. The OMV may be used to maneuver the 
OTV into and out of the constellation. Once at the orbital launch 
point, control Is handed over to the OTV ground control center for 
launch and return. The OTV may use TDRSS, DSN, and Space Station 
communications links. 
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• Regional Data Centers (RDC) - The regional data centers are 
multipurpose facilities or facility complexes providing payload 
operation, data processing, and data archiving services for a class 
of related payloads. Instrument specialists and principal 
investigators may use regional data center facilities to validate, 
access, and analyze data. The centers may also provide instrument 
monitoring and payload operations control center (POCC) services, 
including real-time payload operation and quick-look monitoring of 
engineering and scientific data. Alternatively, the POCC function 
may be accommodated in separate facilities. 

• Remote Customer Facilities - Commercial customers, as well as some 
others, will have their own facilities for payload operation and 
control and data reception, archiving, and analysis. A remote 
customer facility may be connected directly to the data distribution 
network or to a regional data center. When tied to the RDC, the 
customer facility can utilize the support services available at the 
RDC. 


• Engineering Data Center - The Engineering Data Center(s) provides 
archival storage of Space Station and platform engineering data. 

This center will support program and customer requests for Space 
Station Program historical data. 

• Optional Payload Control Center - A payload control center may be 
provided at the Space Station Control Center to provide short term 
support, additional support for payload checkout and special or short 
term mission operations, such as some technology development missions. 

• NSTS Orbiter and Control - The orbiter is the means of Space Station 
deployment, construction, and resupply. All ground-to-orbit 
transportation is assumed to be handled via Shuttle orbiter. Two way 
communication is required to facilitate maneuvering through the 
constellation and docking to the Space Station. The NSTS orbiter is 
controlled from its existing Mission Control Center, as well as by 
the onboard crew. 
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• Deep Space Network (DSN) - This network is the primary means for 
communication between the OTV control center and the OTV from orbital 
launch through geostationary orbit operations and return to 
rendezvous with the Space Station. It also provides a contingency 
command and telemetry link for Space Station communications. The OSN 
will handle only spacecraft data in this backup role. Command and 
telemetry data will be transferred directly with the SSCC. 

• Launch Integration Facilities - These ground facilities provide 
verification of launch readiness for payloads and SSPEs. Launch 
integration facilities are assumed to be remote from the SSDS ground 
element. The relationships may include both software and simulation 
support, as well as interface control. 

• Contractor Facilities - The contractor facilities at which Space 
Station modules and upgrades are being manufactured will be supported 
in their validation and integration tests. The primary support to 
the facility is expected to be in the development and delivery of 
simulation models, and in software development and integration. 

• Development, Simulation, Integration, and Training - Support 
functions anticipated include the development and integration of new 
and modified software, software uplink, integration of customer 
payloads, end-to-end communications checkout, use of flight equipment 
in lieu of GSE, crew training, and construction of simulation models 
for use at remote sites. 

• Other Communi cations Links - Provisions to allow customers to 
communicate with their payloads outside of TDRSS/TDAS are to be 
supplied by the customers. These include direct space-ground links 
and other satellite relays. These links are most likely to be used 
by foreign customers desiring little delay in transmitting commands 
and receiving data and by customers requiring complete security of 
their data. 

• Technical and Management Information System (THIS) - The TMIS will be 
used to support the management of the SSP and engineering development 
and integration of the Space Station elements. This program element 
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will be involved in establishing schedules, monitoring and 
controlling resources, managing budgets, maintaining manuals and 
procedures, developing NSTS manifests, controlling inventories, and 
developing and managing the Space Station configuration. The SSDS 
provides the THIS with station operating data, and the THIS provides 
the SSOS with configuration, planning, and programmatic data. 

Frequent data interchange between the SSOS and the THIS will be 
required. Details of these interchanges will be developed during the 
SSP preliminary design. 

• EVA (HHU, EHU) - EVA support systems, including the HHU and EHU will 
be monitored by the SSDS and may be automatically maintained on the 
Space Station using SSDS support services. The SSDS will also 
maintain EVA communications, including ground links and operations 
and procedure support. 

4.2.3 SSIS/SSDS Functional Boundaries 

With the many SSPEs and functions performed by these elements, it becomes 
necessary to establish criteria for inclusion in or exclusion from the SSIS 
and the SSDS. These criteria are discussed below and applied to determining 
SSIS and SSDS boundaries. 

Criteria For Inclusion in SSIS 


An SSP element or function is to be included in the SSIS if 

1 . The element or function is in the end-to-end data flow . The 
end-to-end data flow extends from the customer's facility to his 
payload, from the engineering data center to the Space Station 
hardware elements, and from the platform or free-flyer control 
centers to the platforms or free-flyers. 

2. The element or function is a Space Station or Platform Core or 
Customer Unique Application . Space Station and platform core systems 
and customer-unique applications, both onboard and on the ground, are 
considered to be part of the SSIS, as they are end points for data. 
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Core systems maintain the environment in which those using Space 
Station Program services operate. Customer-unique applications are 
performed by customer supplied subsystems implementing functions 
unique to their applications. Customer-unique applications may be 
supported as SSIS customer services, but only to the extent 
negotiated between the customer and the Space Station Program. This 
criterion incorporates requirements of Reference 5. 

3. The function or element performs services dedicated to the SSIS. 
which the SSIS must have to operate . This criterion becomes a 
catchall for elements or functions which may be unclear or omitted 
under criteria 1 and 2. No new elements or functions were included 
in the SSIS under this criterion, but it does serve to confirm 
several elements and functions as being a part of the SSIS. 

4. The function or element is in the SSDS . The SSDS is defined to be a 
wholly contained subset of the SSIS. Therefore, any element or 
function found to be in the SSDS must also be in the SSIS. 

Criteria for Inclusion in the SSDS 


An element or function is included in the SSDS if 

5. The element or function provides a core service . All data processing 
and data management services provided to the Space Station and 
platform facility subsystems are included in the SSDS. These 
services may be implemented in space or on the ground. This 
criterion incorporates requirements of Reference 5. 

6. The element or function provides a standard customer service . The 
standard customer services are understood to include those services 
available to any customers, whether in space or on the ground. 
Standard services should be defined in response to requests from 
multiple customers. Some standard customer services will be included 
in the SSIS, but not in the SSDS, per Table 4-2. This criterion 
incorporates requirements of References 2 and 5. 
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Table 4-2. Customer Standard Services in SSIS, Not in SSDS 



Rationale 

Applicable 
paragraph 
from Ref. 2 

Standard customer services 
not in SSDS 

Extended 

service 

Multi 

program 

TMIS 

service 

• Payload data processing beyond 
level 0 

X 



3-1.1, 

3.1.3, 

3.3.1 

• Data archiving beyond 
that necessary to ensure 
satisfactory delivery to 
the customer’s designated 
facility 

X 

X 


3.1.6, 

3.4.1 

3.4. 1.1 
3.4. 1.3 

• Facilitate routine data 
analysis services 

X 



3.3.3 

• Access to Space Station 

programmatic, administrative 
and descriptive information 
(Note: engineering and some 
operations information are 
provided by SSDS) 



X 

4.2.1 

• Data exchange among 
customers 

X 

X 

X I 


3.1.7 

5.4.1 

• Audio and video recording 
and playback between 
elements 



5.2.3, 

5.2.6, 

5.3.3 

• Long term mission planning 
(not including mission 
operations) 



X 

7.1.2 

• Remote Work Stations at 
customers home institution 

X 



6. 1.5. 2. 3 


^Onboard record and playback service* for both audio and video are in SSDS 


7. The element or function manages data inboard of sensors and 

effectors . This criterion is a clarification of criteria 5 and 6, in 
that it excludes the hardware elements (sensors and effectors) from 
the SSDS. 

8* The element or function manages data prior to delivery to or after 
receipt from customers or operators . This criterion clarifies the 
customer and operator ends of the SSIS/SSDS boundary. The end-to-end 
data flow includes institutional facilities, such as TDRSS, that 
cannot be a part of the SSDS. However, the associated data 
management functions provided by the SSP are tested by this criterion 
for inclusion. 
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Criteria for Exclusion from the SSDS 


9. The element is a unique sensor/effector/special purpose processor 
embedded in a system . This criterion compliments criterion 7 by 
excluding elements which are more appropriately part of nominally 
autonomous systems. These systems may still contribute status data 
to the SSDS and receive operating commands such as mode and 
configuration changes. 

10. Element or function is a multiprogram facility or service used by but 
not dedicated to the SSP . This criterion adds a restriction on the 
SSDS scope to exclude institutional facilities and systems. 

The elements and functions included in the SSIS and in the SSDS are shown in 
Table 4-3. The criteria by which the decision was made are indicated. 


Table 4 - 3 . Development of SSIS and SSDS Boundaries 



SSIS criteria 

SSDS criteria 

Exclusions 

um 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 





End 







Mng 









Ded 



User 

Mng 

data 


Multi 




Space station program 


RFP 

SSIS 

In 

Core 

std 

inbd 

before 

Embed 

prog 

In 

In 

In 

element/funtion 


def 

serv 

SSDS 

serv 

serv 

data 

trans 

proc 

serv 

SSP 

SSIS 

SSDS 

GPS 










7 

No 

E9 


Polar platform (POP) 

V 










Yes 

m 

mm 

POP ground data handling 

V 



V 


V 


V 



Yes 


K*fl 

POP control 

V 










Yes 

Yes 

Yes 

Co-orbiting platform (COP) 

V 


V 

V 


V 

V 

7 



Yes 

Yes 

Yes 

COP control 

V 

7 

V 








Yes 

Yes 

Yes 

Free fliers 

V 


V 

V 







Yes 

Yes 


Free flier control 

V 

V 

V 








Yes 

Yes 


Space station 

V 

V 

V 

V 

7 

V 

V 

V 



Yes 

Yes 

Yes 

Space station control 

V 

V 

V 

V 

V 






Yes 

Yes 

Yes 

TDRSS 

V 





J 


V 


V 

Yes 

Yes 

No 

Network control 

V 





V 




V 

Yes 

Yes 

Yes* 

Data distribution network 

V 





V 


yj 


V 

Yes 

Yes 

Yesl 

Data handling center 

V 

V 

V 

V 


V 

V 

7 



Yes 

Yes 

Yes 

OMV services 

V 

V 

V 

V 


V 

V 

V 



Yes 

Yes 

Yes 

OMV control 

V 

V 

V 

V 


V 

V 

V 



Yes 

Yes 

Yes 

OTV services 

V 

V 

V 

V 




V 



Yes 

Yes 

Yes 

OTV control 

V 

V 

V 

V 


V 

V 

V 



Yes 

Yes 

Yes 

Core systems 

v 

V 

7 

V 







Yes 

Yes 

Yes 3 

S.S. payloads 

V 

V 









Yes 

Yes 

No 

Regional data centers 

'J. 

V 


V 




V 


V 

Yes 

Yes 

Yes 1 

Engineering data center 

v 





V 


V 



Yes 

Yes 

Yes 

Customer facilities 

V 










Yes 

Yes 

No 

Customer payload control 

v 

V 


V 




V 



Yes 

Yes 

Yes 

NSTS orbiter 

V 










Yes 

Yes 

No 

NSTS mission control 

V 










Yes 

Yes 

No 

Deep space network 

7 









V 

Yes 

Yes 

No 

Launch integration site 

um 

V 









Yes 

Yes 

No 

Contractor facilities 

■ 

V 









Yes 

Yes 

No 

Development, simulation 

■ 

V 

V 

V 


V 

V 

V 



Yes 

Yes 

Yes 

and training facility 














Alt. communications links 

1 

V 









Yes 

Yes 

Yes 3 

Technical management 

■ 



7 


V 





Yes 

Yes 

No 2 

information system 

1 














1) Portions are institutional and not in the SSDS. 2) See text for explanation of exclusions 

3) Included to define interfaces 
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Free flyer control, Network control Data Distribution and Alternative 
Convnuni cations link are included in the SSOS for the purpose of defining 
interfaces and potential additional requirements placed on these elements. 
These interfaces are discussed in Section 5.2.1. 

The GPS broadcasts signals that are received and processed by the SSPEs. 
However, GPS neither responds to the Space Station nor has knowledge of its 
presence. Hence, GPS meets the requirements for exclusion. 

The Technical and Management Information System (TMIS) serves program-wide 
technical and management information distribution functions for both the SSP 
and for customer services. The customer services provided are more properly 
considered to be part of the SSP than of the Space Station Data System in the 
context of this study. Therefore, the TMIS is considered to be part of the 
SSIS, but not part of the SSDS. 

There are, in addition, some customer standard services in the SSIS, but not 
in the TMIS or the SSDS. These services are excluded from the SSOS because 
the services are considered to be beyond those appropriate for SSOS (extended 
services), or meet criterion 10. Table 4-2 shows the customer standard 
services in the SSIS, including those within TMIS. 

The entries in Table 4-2 require some explanation. "Applicable Paragraph" 
shows the specific paragraphs in Reference 2 which define the required 
standard service. Only those portions of the paragraph implicit in the listed 
Standard Customer Service are intended to apply. Some paragraphs will also 
contain services which are included in the SSDS. 

• Payload Data Processing Beyond Level Zero (raw data) includes all 
processing producing physical units and parameters (Reference 2, 
Appendix B), but excludes unique processing or handling (paragraph 
3.1-3) unless specifically negotiated between the customer and Space 
Station Program. 

• Data Archiving ranges from short term (“ 1 week) to long term (up to 
two years). The short-term archiving (paragraph 3. 4. 1.2) is included 
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in the SSOS to ensure delivery of acceptable quality data to the 
customer. This archiving includes only level 0 data. All longer 
term archiving is an SSIS standard customer service. 

• Facilitate Routine Data Analysis Services provides facilities and 
off-the-shelf software routines to support routine customer data 
analyses. 

• Access to Space Station Programmatic. Administrative, and Descriptive 
Data is expected to be supported by the THIS. The engineering and 
operations data also mentioned in paragraph 4.2.1 should be accessed 
through the SSDS. These boundaries should be either transparent to 
the customer or delineated through user friendly prompts and 
interaction, such that customers can easily access all types of 
information. 

• Data Exchanges Among Customers will often involve archival or 
planning data. To keep the system uniform, all data exchange among 
customers is allocated to SSIS standard customer services. 

• Audio and Video follows the same rules as data exchange, above. 

• Long-Term Mission Planning , in the context of paragraph 7.1.2, 
includes SSPE support services (NSTS, OMV, OTV, etc). Customer 
payload accommodations is also a part of long-term mission planning. 
SSDS will provide all phases of mission operations planning. 

• Remote Work Stations are an extended service to promote 
standardization. 

4.2.4 SSOS/THIS Boundaries 

There are potential areas of overlap between the SSDS and the THIS in 
programmatics. The functions involved were examined in light of the stated 
TMIS objectives (Reference 1, section C-6) and the Customer Requirements for 
Standard Services, (Reference 2). The distinguishing features of the TMIS and 
SSDS identified are discussed below. 
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The THIS features are: 


• Deals primarily with management, development, and long range planning 
for the Space Station. 

• Deals primarily with program managers, designers, and contractors. 

• Deals primarily with engineering development data and programmatic 
data. 

• Development contractors are the primary data sources. 

• Customer interactions are primarily program information and 
coordination of multiprogram services. 

The contrasting SSDS features are: 

• Deals primarily with operation of the Space Station and payloads and 
handling of customer data and commands. 

• Deals primarily with core operator and customer operators. 

• Deals with both real-time and non-real-time operational data and 
commands. 

• Customer interactions are primarily operational and data processing. 

Based on these distinguishing features, the SSDS/THIS boundaries are drawn in 
the areas of potential overlap as defined in Table 4-4. 

4.2.5 SSDS - Subsystem Interface Diagrams 

The onboard portion of the SSDS includes both core and customer services. 

This scope is understood to include all those standard data services 
appropriate for implementation in general purpose processors. The charts that 
follow are a first step in defining a detailed boundary betwen the SSDS and 
the onboard subsystem equipment. This boundary will be further clarified by 
the SSDS Functional Interface Specifications that are to follow in Task 4. 

Figure 4.4.4. 1-1 from the Reference System Configuration has been copied and 

annotated as Figure 4-2 to show a top level view of the SSOS-subsystem 

boundary on the Space Station. The boundary is shown by the bold, dashed 

lines. Note that the Information and Data Management Subsystem (IOMS) is 

fully contained within the SSDS. The Subsystem Data Processors (SOP) for the 

subsystems are also shown a within the SSDS. 
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Table 4-4. SSDS/TMIS Boundary Definition 


Function SSDS responsibility TMIS responsibility 


Logistics Planning 

• Customer and core resupply needs 

• 

New payloads 


• Payload, space station, platform, 

• 

New modules 


Satellite, OMV and ROTV 

• 

Major upgrades 


maintenance needs 

• 

STS scheduling and manifest requests 


• LRU’s on orbit 


Program budgeting and 

• Input requests and status 

• 

Integrated development, monitor and 

scheduling 



statusing of budgets and schedules 

Customer Billing 

• Input data services rendered 

• 

Prepare billing for all services and 
post payments 

Manuals and procedures 

• Payload operations procedures 

• 

Equipment specifications 

reporting 

• Payload maintenance manuals 

• 

Equipment operating procedures 


• Facility operating procedures 

• 

Other facility and equipment 


• Space station system maintenance 


maintenance manuals 


manuals 

• 

Payload interface specifications 


• Emergency procedures 

• 

System specifications 

Configuration management 

• Real time mass and area properties 

• 

Configurational properties 


• Core system equipment status 

• 

Equipment lists, serial nos. 


• Facility configurations 

• 

Equipment histories, failure 


• LRU status 


mechanisms 


• Real time operational data base 

• 

Planning for changes 


• Measurement, monitor and test 

• 

Instrumentation lists 


current configuration 

• 

List of possible system tests 

Inventory Control 

• Spares on board 

• 

Spares in pipeline 


• Spares at facilities 

• 

Location of payloads 



• 

Location of payload spares 



• 

Location of repair parts 

Planning/scheduling 

• Operating schedules 

• 

Programmatic schedules 



• 

Master Plan 



• 

Accommodation plan 

Customer interfaces 

• Receipt and delivery of payload commands 

• 

Customer handbook 


• Receipt and delivery of payload data 

• 

Customer accommodation plan 


• Acquisition and delivery of 

• 

Customer billing 


ancillary data 

• 

Customer priorities 


• Development and use of simulation 

• 

Prior designation of specific commands 


for pay bad integration and 


as restricted or constrained by the SSP 


customer training 

• 

Manifesting customer payloads and 


• Customer authentication 

• Command dictionary maintenance 


supplies 


The numbers 1 through 7 appear. next to the subsystems and indicate the figure 
number in which the subsystem interfaces are further defined. The Propulsion 
System electronics (RCS electronics) are shown to be included within the GN&C 
subsystem (page 416 of the reference configuration). Therefore, no separate 
figure is provided for the RCS. Similarly, the electronics support of 
payloads is included in the SSDS, and no separate diagram is shown for the 
payload and servicing accommodations subsystems. The remaining seven 
subsystems are shown in the interface diagrams of Figures 4-3 through 4-9. 

The Subsystem Interface Diagrams show the subsystem "sensors and effectors" on 
the left hand side. Typical data flows between the SSDS and the sensors and 
effectors are indicated. Subsystem functions performed by the SSDS are 
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Figure 4-2. Information and Management Subsystem Space Station 
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Sensors and Effectors B SSDS 
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Figure 4-3. Electrical Power SSDS Interfaces, Space Station and Platform 
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Figure 4*4. ECLSS SSDS Interfaces — Space Station, Only 


















Sensors/Effectors I SSDS 















Sensors/Effectors I SSDS 
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Figure 4-8. Structures and Mechanisms SSDS Interfaces, Space Station, Only 





indicated in the center boxes on the diagrams. Data flows to and from other 
SSDS functions are also indicated. 

A similar set of diagrams define the platform SSDS - subsystem interfaces. 
ECLS and crew systems are not present on the platforms. Structures and 
mechanisms and Communications are modified as shown in Figures 4-10 and 4-11. 

4.3 FUNCTIONAL ARCHITECTURE OF SSIS 

System architecture is closely related to system design. Only the top level 
of architecture can be presented without specifying the design to a 
significant degree. This section is, therefore, constrained to a very top 
level discussion. Some additional design-independent detail will be provided 
in Section 4.4 in the discussion of SSIS operation. 

The architecture will be presented in a top level data flow diagram, showing 
how the system works from a logical perspective. A more detailed discussion 
will follow on the two major end-to-end data flows, command management, and 
customer data handling. 


4.3.1 Data Flow Diagram Conventions 

Structured Systems Analysis (SSA), Reference. 4, has been used extensively in 
Task 1 to develop the logical operation of the system. Data flow diagrams 
(DFD) are used to provide a graphic presentation of the results of SSA, and to 
show the overall working of the system being analyzed. There are four 
conventions used in data flow diagrams, as illustrated in Figure 4-12, etc. 

• External agencies enter data into the system and receive data from 
the system. They do not otherwise interact with the system. 

External agencies are designated by squares with a double line at the 
top and left. For simplicity of the diagram, an external agency may 
be duplicated on the diagram. A diagonal line across the bottom 
right corner indicates a duplication. 
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Sensors/Effectors | SSDS 
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Figure 4-10. Structures and Mechanisms SSDS Interfaces, Platform, Only 



Sensors/Effectors I SSOS 
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Figure 4-11. Communications and Tracking SSOS Interfaces, Platform, Only 



AN EXTERNAL AGENCY A PROCESS IS 

IS IDENTIFIED BY IDENTIFIED BY A 

A SQUARE: ENTERS. RECTANGLE WITH ROUNDED 

RECEIVES DATA CORNERS: TRANSFORMS DATA 



OATA 

FLOW 


A 


0004 


REPEATED OATA STORE 


AN EXTERNAL AGENCY OR 
A DATA STORE MAY BE 
REPEATED TO SIMPLIFY THE 
DATA FLOWS 


0002 


DATA STORE 


S0003 

REPEATED 

EXTERNAL 

A6ENCY 




DATA FLOWyl 


A REPEATED EXTERNAL AGENCY 
IS IDENTIFIED BY A SQUARE 
WITH A SLASH IN THE LOWER 
RIGHT CORNER 


A 


0004 REPEATED OATA 


STORE 


A REPEATED DATA STORE 
IS IDENTIFIED BY AN 
OPEN ENOED RECTANGLE 
WITH A TRIANGLE 


Figure 4-12. DFD Symbol Conventions 


• Processes transform flows of data, usually in some fundamental way 
that alters its form and content. A process is designated by a 
rounded corner rectangle. 

• Data Stores contain data to be made available to other processes when 
the processes do not necessarily take place in immediate sequence. 
Therefore, the data in a data store should have a significant 
lifetime. Data stores are designated by extended, open sided 
rectangles. Data stores may also be duplicated to simplify the 
diagram. 

• Data Flows identify the data moving among processes, data stores and 
external agencies. The data flows are designated by labeled arrows. 

Structured systems analysis is used to develop multiple levels of detail to 
describe what the system does. The top level (Level 0 DFO) shows the entire 
system in its simplest form. The level 0 analysis concentrates on the 
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end-to-end paths connecting external agencies. It becomes an outwardly 
focused description, focusing on the questions, "Who will be using the 
system?", "What do they want the system to do?", and "What are the major data 
input to the system?." The processes depicted are very top level and 
generic. Subsequent levels of OFDs will add progressively more detail. 

4.3.2 Characterization of the SSIS 

The first step in an SSA is to ascertain the answers to the above questions. 
These responses, in appropriate detail for an SSIS Level 0 DFD, are: 

a. Customers will use the system to develop payloads, develop software 
and command sequences, command payloads and receive data. 

b. Operators will use the system to command the Space Station and 
associated flight and ground SSPEs and receive the data required to 
operate these systems. 

c. Contractors will use the system to develop software and verify SSPEs. 

d. Payloads will interface with the system, receiving required commands 
and ancillary data and generating data to be returned to the customer 
and/or operator. 

e. SSPEs, including core systems, facilities, and constellation 
elements, will interface with the system, receiving required control 
and generating operating and status data. 

f. THIS will interface with the system, providing program management 
control and requiring programmatic and technical information. 

4.3.3 Operation of the SSIS - How the System Works 

The team used SSA to develop the data flow diagram of Figure 4-13. Key 
definitions for the data flow diagrams are provided, and the major functions 
of the SSIS identified in the analysis are described in the following 
paragraphs. 
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4. 3. 3.1 Level 0 DFD Definitions . The following definitions will aid in the 
understanding of the Level 0 Data Flow Diagram: 

t Payloads are the customer supplied packages mounted in or on the 
Space Station. Some payloads will utilize Space Station data 
processing and/or operator services. 
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Figure 4-13. SSDS Level 0 DFD 
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• Constellation Elements include those spacecraft and their payloads 
flying in the proximity of the Space Station. Most constellation 
elements will use the Space Station as a communications node. The 
Space Station will also control the maneuvers of these vehicles. 
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• Polar and Coorbiting Platforms are unmanned, multimission spacecraft. 
The Polar platform(s) will operate independent of the Space Station 
using their own communication links through TORSS. The coorbiting 
platform may use the Space Station as a communications node. If it 
remains in line or sight of the Space Station, or it may operate 
independently. 

• Customers are those utilizing Space Station services, primarily 
commanding payloads and receiving data. Customers may be either 
onboard or on the ground. 

• Operators are Space Station Program employees, both onboard and on 
the ground. 

• Contractors are designers and developers of Space Station equipment 
and software. 

• Data Processing Resources include the computers, storage devices and 
networks supporting the SSDS facilities. 

• Core Systems are the systems that maintain the environment in which 
the customers and operators perform their functions. 

• TMIS is the Technical and Management Information System. The TMIS 
supports the SSOS by providing information and coordinating 
multiprogram resources. 

• Core Status is a data store containing the status and monitoring data 
for all core systems and SSDS facilities. 

• Payload Status contains the status and monitoring data for all 
payloads. 

• Master Plan is provided by TMIS and contains program schedules. 

• Restricted Commands are those payload and core commands which could 
endanger the health and safety of the Space Station, or its payloads, 
and constellation elements. 
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• Constrained Commands are those payloads which require coordination 
with other customers and core systems to ensure that customers do not 
interfere with each other and to coordinate Space Station Systems 
support of customer requests for services. 

• Unrestricted Commands are those that are neither restricted nor 
constrained. 

• Executable Commands are restricted or constrained, but cleared for 
execution on a specific schedule. 


4. 3. 3. 2 Level 0 Data Flow Diagram 


Manage Customer/Operator Supplied Data (1.0) - This function receives both 
real-time and bulk payload and core systems data and transmits these data to 
the customer's and operators. 


Manage Customer/Operator Supplied Data (2.0) - This function receives payload 
and core commands and data from the customers and operators. Operators will 
always provide the core commands and data. Both customers and operators may 
command payloads and enter data destined for the payloads. The function will 
pass unrestricted payload and core commands and all payload data on to the 
Space Station, Constellation and platforms and their payloads. Restricted and 
constrained commands are sent to the Scheduling function to be checked for 
execution. The customer or operator entering the command is notified of its 
disposition. 


Schedule and Execute Operations (3.0) - This function provides an environment 
for customers and operators to develop the Space Station, platform, payload, 
and supporting facility operating schedules. The schedules are developed to 
maximize the value of payload output within the constraints of SSP resources. 
The execute operations portion of the function dispatches commands to execute 
operations according to the schedule. Restricted and constrained commands are 
checked to determine whether they are executable under the conditions at the 
requested execution time. Those which are executable are passed on to the 
payloads or core system. Those not executable are arbitrated with the 
operator and customers involved and scheduled for execution, if possible. 
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Operate Core Systems (4.0) - Evaluates and processes core system sensor data 
and generates system operating commands. Many of these commands are generated 
autonomously within this process. Commands which can be generated and 
executed by the process are governed by system operating mode. 

Manage Core Facilities (5.0) - Performs any necessary reconfiguration of the 
facilities. The data processing facilities are notified of scheduled events 
affecting their operation. Limitations have been taken into consideration as 
SSP constraints in the scheduling process. The function will also notify 
Operate Core Systems (4.0) to disconnect operating power from payloads showing 
evidence of serious malfunction or exceeding prescribed operating power 
limits. Standby power will not be disconnected unless the Space Station 
crew's health or safety are endangered. 

Develop. Simulate. Integrate and Train (6.0) - This function serves customers, 
operators and SSP contractors by configuring and executing simulations to 

e Develop new software 

• Verify and integrate new software 

• Verify and integrate new hardware 

e Deliver simulation models to customers and contractor facilities 

e Train operators to operate the Space Station, platforms, and selected 

payloads 

• Train customers in the use of the system 

e Verify end-to-end communications links. 

Support Space Station Program (7,0) - This function provides logistic 
requirements and SSIS resource usage to the TMIS. It also provides 
maintenance of SSDS facility and payload manuals and procedures, facility 
spare and repair parts inventory control, and operating configuration 
management . 

4.3.4 End-to-End Command Management and Oata Handling/Delivery 

These two major, end-to-end functions of the SSDS were selected for further 
elaboration due to their importance. 
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4. 3. 4.1 Command Management . The SSDS command management problem represents a 
demanding set of requirements unique to the Space Station program. As 
described in the operations concepts and requirements, there is a desire to 
meet the following needs: 

• The value of the Space Station and platform payload and mission 
operations should be maximized within constraints of limited 
resources and safety. 

• It should be possible for customers to command their payloads in real 
time or with stored commands, from space or ground, for 
non-restricted, and restricted and constrained commands. 

• Non-restricted commands should receive no further checking beyond the 
address of the payload. Ideally, restricted and constrained commands 
should be allowed in real time also, as long as the customer is 
operating within the resources and constraints that have been 
negotiated. 

• Autonomy and customer operations and commanding should be supported 
to the maximum extent possible, with minimum delays and schedule 
constraints. This implies less reliance than in the past on the use 
of integrated timelines and schedules which must be developed long in 
advance for all customer operations. 

• Customer privacy should be supported, with commands from some 
customers being encrypted. 

• The personnel operations activity and customer specific development 
required to perform command management should be minimized. 

• Space Station health and safety must be protected, and customers must 
be inhibited from interfering with each other. 

In summary, the steps in implementing the command management data flow to be 
described in Section 6 (figures 6-3 and 6-4) are: 
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• The sender is authenticated, and the command and its destination is 
validated as being authorized for the issuer (customer or operator) 
for the time the command is sent. 

• Data and commands destined for the core system may be subject to 
checking depending on the authorization of the operator issuing the 
command (e.g., not all operators will be allowed to issue all 
commands) . 

• Customer commands are checked for their classification as restricted, 
non-restricted, or constrained. 

• Non-restricted commands and data other than commands are passed 
directly to the core or payload with no further checking beyond the 
address of the destination. 

• Restricted and constrained commands receive command management, with 
conditions for executability of the commands checked by one of 
several alternative processes. 

• Some restricted and constrained commands may be processed for 
immediate execution, while others are processed for later execution. 
Those commands accepted for later execution may become not executable 
before their scheduled time because of unforecasted system or payload 
status changes. 

• Those restricted or constrained commands which can be executed 
immediately are routed directly to their destination without further 
delay. 

• Those restricted or constrained commands which are entered by the 
customer for execution at a later time are checked for executability 
under the conditions scheduled for the time Of execution. Commands 
executable at their scheduled time are held until the time for their 
release and routed to the payload. Changes to the schedule resulting 
from equipemnt failure, loss of capability, or preemption by higher 
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priority may cause commands being held for later execution to become 
not executable. These commands so affected will be treated as any 
other "not executable" command. 

• Commands which are not executable are referred to the customer and/or 
operator for scheduling. 

• Disposition is reported back to the customer or operator at several 
points: 

upon acceptance or denial of the command 

upon scheduling of the command for later execution 

upon delivery of the command to the customer built-in unit (BIU) 

port 

perhaps at intermediate points 

e All disposition is reported to the customer/operator entering the 
command. 

• All processing is consistent with customer real-time payload 
operation from space or ground, except for disposition of not 
executable commands. 

The following discusses some of the options and issues related to meeting the 
above requirements. Options are classified by each of the following steps: 

• Options for the off-line analysis of customer command operations and 
classification as to Whether they are non-restricted, constrained, or 
restricted. 

e Options for the on-line process of classifying a command when it is 
issued by the customer and received by the SSDS. 

e Options for checking restricted and constrained commands to determine 
whether they are executable. 

The final design for command management will be developed in Tasks 2, 3 and 
4. Some of the activities for which options will be developed and trade 
studies conducted are discussed below, together with one or more of the 
possible options. 
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First, the customer command operations must be classified as restricted, 
constrained, or non-restricted. This classification must be done no matter 
how the command management is implemented. 

One option for this classification and command development process involves 
building a command dictionary as illustrated in Figure 4-4. The dictionary 
would contain command identification information, "command keys" which 
initiate execution of the operation, and command restrictions and 
constraints. (Note that the end-to-end command flow is shown in the data flow 
diagrams in section 6. Figure 4-14 illustrates the command classification and 
command dictionary development process which is normally performed offline to 
support the command management flows.) 


The proposed operation is analyzed against 1) a preselected list of Space 
Station resources which may limit operations (e.g., power), 2) potential 
interferences with sensitive Space Station systems and payloads, and 3) 


Operation 



Figure 4-14. Customer Operation Commands Sequence Development 
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potential sensitivity to interference from projected payload and Space Station 
operations. The command operation is classified according to restricted, 
constrained, or non-restricted. If restricted or constrained, the specific 
conditions for execution are defined. 

Customers may use combinations of operations contained in the command 
dictionary to construct operational sequences for real-time or scheduled 
control of their payloads. The classification of the set and of the 
conditions for execution may be carried to higher and lower levels to allow 
customer flexibility in building commands without repeated review. However, 
each operational sequence must bear the highest classification of the 
constituent command sets. 

The second area for options development relates the results of the off-line 
analysis of customer command operations to implementation of the on-line 
command management functions (see Figure 6-3). There are several options for 
implementing this command management function. All will likely utilize some 
form of the command header, and thus some background is needed to explain this 
concept. 

Customer command messages will likely be in the form of "messages" or 
“packets" (though this need not imply packet switching). Such command packets 
will have a header (and trailer) which wrap around the customer command, with 
information to be supplied in a standard format (which is to be determined in 
this study). This header information must have the destination address (the 
payload) so that it may be routed over the ground and/or on-board transport 
networks, but the header may be used for command management as well. For 
example, the command headier could specify the command classification 
(restricted, constrained, or non-restricted). In fact, the addressing scheme 
might itself be used for command classification as noted below. 

If this header were customer supplied and not checked, it would imply trusting 
the customer to not intentionally or unintentionally mis-identify the command 
(e.g., labeling a constrained command as non-restricted). Checking might also 
be necessary to prevent customers from sending commands to the wrong payload. 
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or a saboteur from sending commands to a payload. If SSOS supplied, it 
implies maintenance of a database for all customer commands so that the SSDS 
can perform the classification, which will require significant effort. 

When a customer issues a command (real time or stored), the SSOS must first 
verify that the command is coming from a valid customer authorized to send 
commands to the specified payload. The command must then be managed as 
restricted, constrained, or non-restricted. Two options to performing this 
management are: 

e In one option, the results of the analysis of the customer command 
operation could be reflected in the command header and the data 
transport network and affect how commands are routed. Commands with 
addresses which imply that they are not restricted would be routed 
directly to the payload — in effect having their own logical path. 
Restricted or constrained commands would be routed to intermediate 
destinations for further checking. 

This option implies trusting the customer to identify the command correctly, 
and also implies an SSOS ability to read and check restricted or constrained 
commands. However, the command distribution capability (e.g., the data 
network) would automatically route non-restricted commands in real time, and 
no separate unrestricted command databases would need to be employed other 
than the network routing tables. However, the database for reading and 
resolving restricted and constrained commands may be extensive. Customer 
payload software could further be required to ignore unresolved, restricted 
and constrained commands and this would have to be verified in testing. 

e Another option would be to require the customer to pre-define 

concatenated versions of all restricted or constrained commands for 
use in a command dictionary maintained by SSDS. The customer would 
issue "command keys". Command keys would have address headers so 
they could be routed to the right payload. The SSDS would use the 
command dictionary to check the condition for execution of the 
commands and accept commands whose requirements are met at the time 
indicated for execution. Resolution of restricted and constrained 
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commands would be simplified at the expense of an extensive SSDS 
database maintenance task. Non-restricted commands may be passed 
directly through to the payload or may be required to be recognizable 
by the SSDS. 

Validated command sequences triggered by the key commands could be stored on 
the ground or on-board the Space Station, either in the customer's processor 
or in an SSDS processor utilized by the customer as a standard service. This 
processor would translate all key commands into the pre-stored sequences. 
Non-restricted commands would be forwarded directly to the payload, while 
restricted or constrained commands would be subject to checking conditions for 
execution. The command dictionary would be required to keep a list of at 
least all customer restricted and constrained operations and their command 
keys, as well as information on constraint and restriction conditions. 

In both options, a mechanism must be provided to merge or otherwise issue the 
core commands (e.g., connect power) necessary to implement the payload 
commands. Knowledge of Space Station and payload status is required at the 
location where this command management is performed. 

The final area for options development is resolution of the commands which 
exceed constraints or violate restrictions. This condition may result from 
circumstances such as: 

• Customers attempting to operate their equipment in a manner not 
anticipated in the schedule. 

• Station equipment failure or other loss of capability. 

• Schedule preemption by a higher priority operation. 

• Error conditions. 

The SSDS should attempt to resolve these commands. Resolution could be 
determined by an operator, automatically by the SSDS software, or 
interactively, with or without customer involvement. An interactive procedure 
with customer involvement is currently preferred. 
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If the command cannot be scheduled for execution at a time satisfactory to the 
customer it must be rejected. The customer must then replan the operation. 

In order to replan the operation, the customer must be informed of the reasons 
for rejection, and may require assistance in replanning. The SSDS will be 
required to supply the reasons for rejection, and the Space Station Program 
should be prepared to assist in replanning. 

One implementation of the command management process is illustrated in Figure 
4-15. When a customer or operator enters a command key, the SSDS will perform 
the following functions: 


SSDS 



Figure 4-15. End-to-End Command Management 


a. Validate P/L commands 

e The Customer/Operator is validated as one who is authorized to use 
the system. 
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• The address for the input is validated as authorized for the customer 
or operator. 

• Data other than commands destined for the core system, payloads and 
constellation elements are passed directly to their addressed 
destination. 

b. Check P/L Command Restrictions/Constraints 

• Payload commands are checked against the command dictionary and 
confirmed as restricted, constrained, or non-restricted. 

• Non-restricted commands are sent directly to the payload, core 
system, or constellation elements. 

• Restricted and constrained commands are sent to the scheduling 
process for disposition. 

c. Develop Ops Events Schedule 

• Disposition is reported back to the customer or operator. 

• Conditions for executability of restricted or constrained commands 
are checked. Those commands which can be executed immediately are 
passed on to their destination. Other executable commands are time 
tagged and loaded into the Operating Events Schedule to be delivered 
at their scheduled time. 

• Commands which are not executable are referred to customer and 
operator for scheduling. 

• All disposition is reported to the customer/operator entering the 
command. 

• All processing is consistent with customer real-time payload 
operation, except disposition of not executable commands. 
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4. 3. 4. 2 End-to-End Customer Data Handling/Delivery 


This second major end-to-end data flow is illustrated in Figure 4-16. The 
customer payload receives real-time ancillary data from the SSDS and merges 
the data into the payload data stream. Payload data required by the customer 
in real-time are designated by the payload for real-time delivery. These data 
are kept separate from bulk data in order to expedite delivery. Bulk data are 
accumulated onboard for scheduled, high data rate downlink. Once per orbit 
downlink of bulk data will accommodate all requests from Reference 3. 

However, optimum link usage and onboard storage may require other schedules. 

The data downlink and distribution is governed by priorities developed 
interactively among customers and operators. 

Downlink data are captured, and delivered to a handling process for standard 
processing. The data are sorted according to customers, processed to level 0, 


Onboard SSDS 
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and delivered. Online storage is maintained for 12 hours to support 
quick-look monitoring by the customer and to ensure delivery. Offline storage 
is maintained for one week after receipt of satisfactory quality data by the 
customer. Data accounting is provided to the customers, showing the status of 
all payload data. 

Archival storage for up to two years, as well as level 1A processing, are SSIS 
standard customer services. Additional archival storage and customer unique 
processing are beyond the scope of the SSIS. 

4.4 OPERATIONS CONCEPTS FOR THE SSIS 

An operations concept for the SSIS was developed to describe how customers and 
system operators would use the SSIS in support of their missions. The purpose 
of this operations concept is to describe the ways in which people will use 
the SSIS to accomplish all phases and modes of their operation. The operation 
concept also serves as a preliminary description for potential customers and 
operators of the way the SSIS works so that they may provide inputs to the 
system requirements refinement and design. 

Two views of SSIS operations are provided; the customer's perspective 
(paragraph 4.4.1) and the operator's perspective (paragraph 4.4.2). The 
customer's perspective describes how a Space Station or Platform customer uses 
the SSIS to plan missions, develop and integrate payloads and support systems, 
perform mission operations, and acquire and use the mission data. The key 
goals driving this operations concept have been (1) to provide maximum 
operational autonomy for the customer, (2) to make the integration of customer 
systems with the Space Station and Platforms simple, straightforward, and 
relatively inexpensive, and (3) to provide the customer with a reasonably 
broad set of options for planning and implementing his Space Station and/or 
Platform mission(s). 

The operator's perspective describes the SSIS operations concept from the 
viewpoint of the Space Station operations manager. Space Station and Platform 
resources scheduling, crew scheduling, overall mission integration, core 
system maintenance, training, and system upgrades are key concerns. 
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The above perspectives deal with the operation of the Space Station and 
platforms after IOC and between growth cycles. A buildup scenario has also 
been provided (paragraph 4.4.3) to identify the capabilities required during 
buildup and the SSOS functional requi rements . Growth cycles are examined in 
paragraph 4.4.4. 

From the above, the operational design drivers are identified (paragraph 
4.4.5) to provide guidance to the remainder of the study. 

4.4.1 SSIS Life Cycle Operations - Customer Perspective 

This section describes a chronological sequence of operations related to the 
customer. For the purpose of this discussion, a customer is defined as an 
individual or organization with an objective related to the Space Station 
Program and has primary responsibility for a payload and for the use and 
interpretation of data provided by that payload. The customer will receive 
support from the SSIS to accomplish the mission objectives. Inherent in this 
description is the philosophy that each customer will differ in the degree and 
type of services that he will use; customer costs vary accordingly. This 
concept implies the need to clearly inform the customer of the methodology for 
getting an experiment on the Space Station or the Platform, and of these 
optional services and related costs available with each option to support his 
activities. 

Basic to the customer perspective is that most operations are transparent and, 
with few exceptions, all interfaces standard. 

Some of the operations described in this section may become part of the THIS 
as its definition becomes firm. Since those portions of the THIS needed for 
customer operations are contained within the SSIS, no distinction is made 
between the SSIS and THIS in discussing operations from the customer's 
perspective. 

4. 4. 1.1 Familiarity and Agreements . Many prospective customers will know the 
Space Station Program well enough to initiate inquiries into becoming a 
customer and to promote their own missions. However, it is to NASA's interest 
to agressively seek customers by supplying program information on capabilities 
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and services offered. Workshops, seminars and public releases can be used as 
information dissemination vehicles. NASA may consider assigning prospective 
customer relations to a specific organization as an option. 

In the age of personal computers, it is desirable that NASA maintain a menu 
driven, publicly accessible data base that describes the Space Station Program 
details as selected by the viewer. This will be enhanced to enable an easy 
transition from the general public to a Space Station Program (SSP) customer. 
It is envisioned that SSP customers will vary from college graduate students 
working on theses to highly competitive commercial customers similar to the 
STS electrophoresis experiments which may yield production of life saving 
pharmaceuticals. Figure 4-17 is an example of a menu provided to the public 
simply by dialing an 800 number or some equally Inexpensive access. The 
content of this information and procedural data base will evolve with the 
Space Station Program. 

The NASA will maintain a customer handbook available in either printed form or 
by electronic transmission. This handbook would be available in different 
levels of detail depending on the customers level of interest and 
negotiation. The sincere customer will obtain a thorough description of the 
services that could be provided as well as the actions expected of a 
customer. Example topics covered will include: 

• Space Station Program general description 

• Management procedures 

• Available resources 

• User interface 

• Scheduling 

• Security 

• Space platforms 

• Space Station Attached facilities 

• Space Station Laboratory Facilities 

• Crew services 

• Flight preparation 

• Launch and landing operation 

• Orbital operations 




Figure 4-17. Space Station Information Service 

• Customer responsibilities 

• Cost estimating procedures and data base. 

• Current & Projected Nonproprietary Payloads & Missions 

This handbook would be supplemented by meetings with cognizant NASA personnel 
as well as workshops. 

Historically the programmatics of having an experiment accepted on a NASA 
program involves lengthy, time engaging, very formal interface meetings and a 
mountain of paper. To a large extent, this process will be codified and 
reduced to an interactive dialog through terminals. This trend is exemplified 
in Figure 4-18. 

One electronic process would be explanation of available, measurable resources 
and services versus cost; it would be a NASA policy decision to provide a 
schedule of cost. Figure 4-19 shows examples of measurable items. 
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Figure 4-18. Trends in Experiment Planning 



71 


Other measureables include: 


• Integration and training 

• Storage by duration and media type 

• Communication links and local bus bandwidth 

• Priority servicing 

• Launch and deorbit (by weight and volume) 

• Power 

• Operator time 

• Special facilities. 

• Security/privacy 

Given detailed knowledge of the Space Station Program and costs of service 
from either an electronic data base or a written handbook, the potential 
customer can then prepare and submit a proposal to NASA. The customer's 
proposal could be prepared electronically by providing responses to a standard 
set of queries. 

Successful review and subsequent negotiations would necessarily be performed 
in face-to-face meetings; each customer would then enter into a contractual 
agreement with NASA which specifically describes the services to be provided 
and the associated costs. In many cases, these costs would represent fund 
transfers between NASA offices or reimbursable funds between other government 
agencies and NASA. The extent that these procedures can be made uniform will 
aid in the development of a commercial customer base. 

4. 4. 1.2 Long Term Planning . A traditional source of consternation between an 
experimenter and the Program Office is the lack of synchronization between 
their respective schedules. For example, experimenters must realize that a 
high fidelity simulation of a major payload requires precise definition of all 
interfaces as much as a year prior to the simulation. 

An explicit planning process would synchronize deliverables by all parties. 
This process would be accessible from interactive terminals. The planning 
system would be sufficiently programmed to prompt for delinquent entries or 
inadequate responses. This intelligence would include the ability to suggest 
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adequate work-around during contingencies. Figure 4-20 gives examples of 
issues to be addressed by long-term planning. 

The consequence of interactive sessions associated with this long-term 
planning process would be the definition of specific dates agreeable to both 
parties for milestones associated with the activities typified in Figure 
4-20. Naturally this procedure would be interactive and, when required, 
supplemented with face-to-face negotiations. However, the long-term planning 
process could easily be designed to provide prompting comments to either party 
that would indicate, among other things, time to fulfillment of the next 
milestone and the status of past milestones fulfillment. 


A major function during this phase will be customer familiarization with the 
required standards. In addition, contingency management planning would be 
initiated in order to establish respective roles in the event of payload 
malfunction. This planning would continue to be updated as the project 
progresses, perhaps even supported by a customer failure modes and effects 
analysis . 



Figure 4-20. Integrated Planning Process 


Customer In-House 
Payload Development 
Schedule 
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4. 4. 1.3 Development and Training . As development progresses, details, 

specifically Interface Control Documents (ICDs) must be agreed upon. In 
general, standards will exist. Even so, each customer will have certain 
options and related design decisions such as: 

• Encryption/decryption 

• Higher level protocols 

• Data capture parameters 

• Display page definitions 

• Processing algorithms 

• Command philosophy 

• Command specifications 

• Telemetry measureables 

• Operational constraints 

• Standard core services. 


The standard core services requested by the customer will include avionics 
support (orbit and attitude determination), core resources monitoring (power, 
core data and communications services, ECLSS usage (on Space Station), sensor 
monitoring, etc.), configuration management, generic resource scheduling, etc. 

Payload operations could be simulated on NASA premises or through 
telecommunication from NASA to customer premises. NASA supported simulation 
would include mechanical, electrical, logical, and format test for 
compatibility with the Space Station or Platform data system. 

Higher fidelity simulations may be required for payload operations which have 
complex interfaces to the Space Station or Platform Systems and/or which 
impose risk on the health and safety of the Space Station/Platform. In these 
cases, their operation cannot be made autonomous, and coordinated operational 
scenarios will be required. 

Dependent upon the nature of the payload and the fidelity of the simulation 
chosen by the customer or required for Space Station or NSTS crew training, 
the customer will have to provide varying amounts of information, 
characterizing the payload. Figure 4-21 gives example items. 


C-c^ 
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Figure 4-21. Payload Definition Requirements 


Definition of other payload characteristics may include: 

• Payload design documentation 

• Workstation/payload interfacing software (for Space Station operation) 

• Payload models 

• Malfunction and anomaly procedures 

• Environmental contamination — outputs and sensitivities 

• Power and thermal requirements 

• Fluid dynamics 

• Graphics information; information required for visual modeling 

• Berthed payload dynamics (includes RMS-type operations) 

• Payload retention and deployment specifications 

• Payload tracking (deployed and co-orbiting payloads) 

• Carrier (OMV and OTV)/payload interface specifications and switchover 
procedures for deployment (e.g., hardwire to Space Station vs. RF 
link tracking, telemetry, and command interfaces) 
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To ensure that the customer's payload can be integrated into the Space Station 
or Platform in a straightforward manner, and in order to ensure data 
availability, the customer will have to provide information for simulations. 
This information will vary in detail depending on the complexity of payload 
operations and required coordination with Space Station or Platform systems. 
Discussions will probably begin several years before the detailed simulation 
is required. Initially, only general instrument parameters will be required. 
These will then be refined up to the time that the complete simulations is 
available. At this time customer provided models, or an actual payload 
simulator developed by the customer will be used for simulations and training 
on complex payload operations. 

Training would be mostly applicable when a Customer Mission Specialist (CMS) 
is required. If the Mission Specialist is trained by NASA, this training 
could Include all adjustments, installation, tear down and rebuild with any or 
all specific parts of the customer's payload. Further, a ground operator 
instructor could be co-trained by means of closed circuit television with 
appropriate time delay. 

Other typical training choices for the customer include: 

• SSPE training — OMV and OTV (for co-orbiting platforms), platform 
operations, etc. or subsystems which are subject to customer 
interaction. 

• Instrument control — cameras, thematic mappers, multi-spectral 
scanners, telescopes, sensor pointing. 

• Platform Operations control center capabilities, interfaces, and 
operating procedures. 

• POCC operations training for customers purchasing POCC services. 

• Services training — THIS (or its equivalent for customers), 
scheduling services. 

• Voice communication protocol 
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• Archival data retrieval and analysis. 

• Space Station and Program capabilities and operations. 

It should be noted that no science or payload training will be available on 
the Space Station Program. Thus, such training, as is required may be 
minimized in customer ground facilities. 

4. 4. 1.4 Launch Support and Payload Integration . The customer will be 
actively involved in all integration and in all of the integration and test 
phases of his payload. This section discusses the program support provided to 
the customer during predelivery testing, launch support, transport to orbit, 
and during final integration and test onboard the Space Station or Platform. 

Predelivery testing would principally consist of some levels of simulation, as 
discussed in Section 4. 4. 1.3. The level of complexity of this testing will 
vary from customer to customer. Tests could be as simple as a mere physical 
and functional electrical verification up through a rather complex, high 
fidelity simulation. The location of these tests would, in turn, also vary 
depending on complexity; they could be performed at the customer's facility or 
at a NASA facility. 

Launch support would include a variety of customer support operations such as 
calibration, flight readiness checkout, environmental control, interface 
verification, and other functions that could be performed prior to launch. 
These functions that would be so tested are dependent on the type of payload. 

The final integration and test of the payload would then be performed by the 
crew or the CMS possibly in conjunction with the ground based customers. The 
Mission Specialists will need to perform instrument checks, operational 
checks, and data handling checks. These might include: 

Instrument Checks 


Damage Inspection 
Alignment and clearance checks 
Pressure test 
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Power connection checks 

Basic start-up test (a go, no-go type assessment) 
Thermal checks 

Operation Checks 


Functional Checks 
Communication interface checks 
Temperature 
Cleanliness 

Humidity compatibilities 

Safety constraints (hazardous material handling, etc.) 

Emergency procedures 
Maintenance procedures 

Data Handling Checks 

Instrument calibration and baseline operational checks 
Data capture 

Data reduction algorithm verification 
End-to-end data transmission and verification test 
Software and data hardware verification 
Command verification 

The customer-developed test and verification procedures will be performed for 
assurance that the customer apparatus is performing properly, that no 
unexpected interface problems have occurred, that no transit damage has 
resulted during the launch and transport to the spacecraft, and that the crew 
or CMS has set up the payload to operate as expected. This procedure 
execution phase is shown in Figure 4-22. 


4. 4. 1.5 Operations Phase . 

4. 4. 1.5.1 Status. Customers could maintain knowledge of the current Space 
Station operation by means of remote terminals. Information obtained would 
include that shown in Figure 4-23. 
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Figure 4-22. On-Orbit Test and Validation 



Figure 4-23. Space Station Operational Status 
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As protected by an access code, the customer would also be able to obtain 
specific status information relative to his payload operations such as: 

Current operating schedule 

Projected operating schedule, especially where required resources may be 

impacted 

Current health and safety 

Logistics status (consumer resupply schedule) 

Archival data status (location, amount, accessibility) 

Maintenance schedule 

Status of payload instrument interfaces. 

4. 4. 1.5. 2 Scheduling. In the context of this section, scheduling refers 

to the prearranged timeline execution of payload commands in context with 
operational status. This is in contrast to the planning function which takes 
place over a period of time prior to command execution. Scheduling which 
takes place closer to the time of execution frequently involves conflict 
resolution between requests for limited Space Station or Platform resources. 
The scheduling function must take into account changing priorities and payload 
compliment. 

Principal Investigators or Payload Managers clearly prefer that their payload 
schedules be autonomous; certain payload operations, unfortunately, result in 
potential conflicts between payloads and between any given payload and the 
Space Station or Platform operations. Therefore, scheduling must consider the 
interrelationships between these elements. Constrained and restricted 
commands will be subject to scheduling and timetagging based on numerous 
criteria such as the Space Station or Platform attitude, orbital position, 
interaction between payloads, etc. Unrestricted commands may bypass the 
scheduling function of the customer's discretion, and be delivered directly to 
the payload. 
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There may be more payloads on board the Space Station than can be operated at 
their maximum desired duty cycle because of limited resources. Principal 
Investigators will need to interact with the scheduling function to help 
optimize the output of their payloads within the constraints imposed by the 
limiting resources. 

Outside events, such as emergencies or even transient observational events may 
dictate the desire for short-term schedule modification. The Space Station 
Program must support different time levels of schedule change as, for example, 
monthly inputs (astrophysics), daily inputs (earth observations), hourly 
changes (atmospheric observations). In all cases the SSDS must support short 
term schedule revisions down to the last minute to accommodate changes in 
observations and targets of opportunity. 

4. 4. 1.5. 3 Payload Control. Customer control over payloads will be 
exercised primarily through commands; commands may be entered either from the 
customer facility, the Payload Operational Control Center, from the Space 
Station (includes the co-orbiting platform), or from commands stored or 
generated by the payload. 

Figure 4-24 illustrates the SSIS top level role in payload operations of which 
payload control is one. Not shown here is the aspect that many customer 
commands are not subject to scheduling and pass unrestricted directly to the 
payload, while others will be checked prior to transmission to the payload. 

During the development stage, the customer will provide NASA with a list of 
expected commands and associated results from these commands; this list will 
be updated through operations. All commands will be categorized by the Space 
Station Program according to whether they are unrestricted, constrained, or 
restricted. Unrestricted commands may be exercised by the customer at any 
time without review by the SSP, subject to the limitation that such conditions 
as emergencies or safing modes could prevent the delivery of unrestricted 
commands. Typical unrestricted commands might include: 

• Iris adjustments 

• Filter wheel location 

• Change in focal length 
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• Command Initiation 

• End-Item Command Validation 

• Long-Term Science Data 
Archive 

• Data Processing and Information 
Extraction 


Customer Facility 
Figure 4-24. Payload Operations 



Payload Planning/Scheduling 

- Interactive 

- SSIS Resource Allocation Among 
Customers 

- Support for Alert and Rapid Replanning 
Payload Control 

- Functionally Transparent R/T and SPC 
Support 

- Protection Against Unauthorized Access 

- Command Receipt Validation 
PayloadfAncillary Data Handling 
and Distribution 

- Catalogue, Archive, Manage, Disseminate 

- Transparent Customer Data Delivery 

• Quick-Look in R/T 

• Level 0 Within Negotiated 
Time Period 

- R/T and Post Mission Engineering and 
Operations Data 


Payload Operations 
Control Center 


1 Regional Data 
Center 


SSIS Standard Customer Services 


• Contained gas flow rate 

• Request for video information 

• Shutoff of equipment (no large power surge) 

• Temperature sensing. 

Restricted commands are, by definition, those commands that might involve the 
health and safety of the Space Station or Platform or any habitable portion of 
the Space Station. Typical restrictive commands might be: 

• Power on (significant power surge) 

• Attitude related maneuvers 

• Toxic material control 

• Spacecraft data base modifications 

• Pyrotechnic initiation 

• Component rotation 

• EVA navigational control. 
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Constrained commands are, by definition, those commands that may affect other 
payloads and/or commands that require certain Space Station or platform 
support requiring associated engineering commands. The list of constrained 
commands will vary in time due to a changing payload manifest and an evolving 
spacecraft configuration. Typical constrained commands which may affect other 
payloads are: 

t Gas emission 

• Electromagnetic wave generation 

• Demand for spacecraft resources 

• Communications demands 

• Large thermal changes. 

Typical of the payload commands affecting the spacecraft might be: 

• Observations requiring large scale attitude maneuvers 

• Power bus reconfiguration 

• Module atmosphere pressure changes 

Stored program commands can fall into any of the above categories. In 
general, the customer will have unencumbered control of software embedded in a 
payload. However, restricted and constrained commands must be checked for 
execution. 

One basic requirement of the SSDS is that the customer be granted privacy of 
command and data. Privacy of the command channel can be effected by ensuring 
adequate authentication of the customer identification code prior to 
transmission and permitting encryption. Similarly, the customer's command 
data base and the nature, type and results of his commands must be protected 
by adequate code words. In addition, the NASA will design to ensure that a 
customer command sequence cannot be encroached upon. Security, however, shall 
be the responsibility of the customer, as for example, by providing his own 
encryption/decryption devices as desired. 

In addition to digital commands, the customer may exercise a command process 
through either audio and/or video communication with Mission Specialists. 
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Again, during such operations, these links can be kept private. For certain 
operations including the co-orbiting platform and/or the Orbital Maneuvering 
Vehicle (OMV), the customer could be permitted, within the limits of safety to 
control selected operations by direct interaction. This would require the 
customer's presence at the appropriate control center. 

The customer may incorporate validation into the payload command, either by 
telemetry measurables or by end-item verification. In addition, the customer 
may request the SSDS to provide status throughout the command process, e.g., 

RF lockon, command receipt, and command transfer to the payload. The Space 
Station Program may also provide full duplex verification of command delivery 
to ensure no undetected transmission errors. 

4. 4. 1.5. 4 Customer Data. The customer may receive data at several 

locations: 

• Space Station (for customer Mission Specialists) 

• Orbiter 

• POCC 

• Discipline-oriented regional center 

• Customer premises. 

Data may come from several sources: Payload (real time and delayed), 

ancillary (real time and delayed), payload archives and engineering/core 
archives. The data may be transmitted through TDRSS, or by alternative means 
supplied by the customer. 

Operational aspects of SSIS support for data flow to the customer are shown in 
Figure 4-24. 

With the exception of data received at the Space Station or NSTS, real time 
data will actually be subject to a variety of delays; these delays will not 
necessarily be constant for any given customer or type of data. The 
transmission delay is predictable but may vary for any given task. Even 
though dedicated TDRSS links may be used, transmission and buffering delays 
will still occur. It is, as yet, uncertain whether there will be competition 
for TDRSS links among the Space Station, POP(s) and the COP. To the extent 
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that channels are shares, real time data will be restricted. Given the high 
data rates now projected for some payloads, further buffering may be necessary 
at TORSS White Sands recieving station in order to match the rate of incoming 
data with the available link capacity leaving White Sands. If the data are to 
be distributed from a POCC to the customer's premises, then further buffering 
is likely, in order to accommodate POCC to customers data link rates. Under 
the foregoing conditions, it appears that there are major potential 
differences in system impact between data delivery with only transmission 
delays and data delivery with relatively short delays resulting from in 
transit buffering. Although operations with the SSDS and even the SSIS should 
be transparent to the customer, significant data delays are likely to occur 
unless a single access (SA) link has been scheduled. A design driver will be 
the requirement to minimize these delays and restrictions for the delivery of 
payload and engineering/ancillary data for real-time operations. 

Data received at any site from any source may be processed at a variety of 
levels. Data will be provided by the SSDS as raw data or at Level 0 at the 
customer option, or at level 1A by the SSIS with processing performed at the 
customer's option. At the Space Station and POCC sites the customer can 
perform routine analyses on his data using SSIS standard customer services and 
can perform quick look and routine analyses using SSIS facilities and his own 
software resources. 

One example of customer processing above Level 0 is quick-look data 
processing. The SSDS will provide the customer any selected Level 0 data from 
his payload data stream to allow for quick-look processing in space, at a 
POCC, or at the customer's premises. This data will include the necessary 
ancillary data to support the processing to the desired level. 

Required ancillary data will be selected by the customer during the 
development phase. These data will be provided to the customer coincident 
with his relevant data. Examples of ancillary data are: 

Time 

Configuration changes 

Attitude 

Orbit position 

Water dump status. 
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Pointing/orientation 

Power flux/usage 

EMI map of station 

Thruster firings 

Internal pressure 

Atmosphere composition 

Relative humidity 

Radioactivity exposure 

Chemical contaminants 

Optical environment contaminants 

Crew/operations activity 

Accelerometer data 

OMV berthings/status 

EVA activity 

Internal temperature 

External temperature 

Particulate count 

Particulate types. 

The SSDS also provides the customer with the capability to request ancillary 
data not on his original list. In this case, the data would be retrieved from 
the core data base, whether in space or on the ground. The customer may also 
retrieve data from the core engineering archived data base during its 
retention time of at least two years. 

The customer's ability to process data shall be protected by several 
mechanisms. To begin with, the customer shall have the option to peruse 
quick-look data at the level he selects. Further, upon receipt of customer 
data, should anomalies become apparent, the customer may request repeat 
transmission of data from an SSDS archive for up to 12 hours. Further, this 
same capability exists for data up to one week of relative age with a slightly 
greater time lag for delivery. All of this data will contain a priori 
designated ancillary data. Should the customer desire engineering or 
ancillary data other than a priori designated ancillary data of one week in 
relative age, it may be obtained from short-term archives. Such data would 
also be available for a period of up to 2 years from longer term archives. 
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The customer shall be able to either restrict or authorize access to payload 
data. A standard level of SSDS data privacy will be available to the 
customer. . In addition, the customer may elect to implement his own higher 
level of security. 

4. 4. 1.5. 5 Teleconferencing. Customers may elect video and/or voice 
teleconferencing among several sites on earth and the Space Station and NSTS. 
This teleconferencing capability may be required when missions involve 
different experimenters located at different sites or where experts are 
available at different sites. 

Video teleconferencing would be possible between NASA facilities and the Space 
Station and NSTS using NASA's private telecommunication networks currently 
under development (e.g., NASCOM, Program Support Communication Network) and a 
link to space through White Sands. Optionally customers may tie into the 
video conferencing network by leasing transmission facilities which 
interconnect with the NASA facilities. The number of customers allowed this 
type of direct connection will be severely limited. Further, this type of 
function is limited to standard physical (transmission) and logical 
(compression algorithms) interfaces. Such customers must also provide their 
own equipment. 

Customers will arrange a video conference in advance by calling a central NASA 
point of contact. Since the conference resources are shared among many 
customers, and might be shared with Space Station core operations, delay may 
vary depending upon the degree of contention. It is likely that only one 
duplex, two party conference may be in progress at any given time. However, 
many parties may have "monitor only" capability. 

To schedule a conference, each customer must specify the time, date, duration 
and the location of the "chairman" in control of the conference proceedings. 
The "chairman location" must be at a NASA facility. 

Each conference will be in "near" full motion as NASA's networks employ video 
compression down to 1.544 Mbps; the customer will notice some degree of 
degradation. 
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The transmission among the NASA facilities (including the Space Station) will 
be encrypted (in response to the general requirement placed by Presidential 
Directive on all such transmission). However, encryption to the customer 
premises is the responsibility of the customer. 

Voice teleconferencing, in contrast to video teleconferencing, may be arranged 
on relatively short notice. Customers will see few delays in scheduling. 
Urgent requests, particularly in support of an active mission, may be 
scheduled on the same day. 

Voice teleconferencing may be implemented through existing NASA facilities 
with a link to the Space Station through White Sands. However customers can 
tie into the conferencing network by leasing transmission facilities which 
interconnect with NASA facilities. Customers who do so must provide their own 
equipment. Conferees may also be added using "dial-up" connections over the 
telephone network, though the customer will likely see severe degradation of 
quality in this case. Orbiter teleconferencing capabilities for Polar 
Platform missions are described in SG07700. Capabilities can be scheduled 
through the Platform Operations Control Center. 

Privacy for all links may be provided by virtue of having point-to-point 
transmission facilities. This privacy will apply to the Space Station by 
providing an appropriate receiver. 

4. 4. 1.5. 6 Customer Mission Specialist (CMS). Some customers may desire 

that their own Mission Specialist perform their payload on-orbit operations, 
as was the case with the recent electrophoresis experiment where MDAC supplied 
a CMS as part of the NSTS crew. Feedback from these experiences are providing 
valuable data as to how the SSIS can better serve customer provided CMS 
personnel. The Customer Mission Specialist will operate under the authority 
of the Station Director or NSTS commander, as appropriate, and will perform 
associated payload operations and housekeeping tasks. 

Two aspects of the SSIS functions to support this level of customer 
participation are the need for high fidelity simulations, and the need to 
provide a flexible and efficient near-term scheduling environment allowing a 
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high degree of autonomy for onboard crew personnel. This aspect is also 
addressed in the operator's view of this operating concept. Other items, one 
of which is standard service requirements, are: ready access to a ground data 

base with pertinent experiment and systems data; point-to-point audio and high 
resolution video; and real-time access onboard to Space Station engineering 
and payload data. 

NASA documentation will be provided that describes the requirements for 
selection and qualification of these Mission Specialists. Given selection, 
Customer Mission Specialists will receive training on general Space Station 
operations for approximately two to three months. Examples of training areas 
include: 


• Zero-g orientation 

• Habitability equipment and procedures 

• Activity planning 

• Communications procedures 

• Emergency and safety procedures 

• Exercise and health maintenance routines 

• Housekeeping 

• Information and data management system. 

Naturally, the CMS would prove useful in the event of a contingency involving 
the customer's payload by providing fault isolation support, limited repair 
and modification and part replacement. 

4. 4. 1.6 Post Mission Operations. 

The customer may receive some services after mission completion. This would 
include return of the payload, availability of archived data and data based 
files, analysis of space affects on the physical payload, and analysis of the 
payload data. The analyses, both scientific and engineering, would be based 
on NASA's experience and would include correlation of spacecraft operations 
and status with the particular payload operations involved. Engineering data 
will be archived by the Space Station Program for at least two years. 

Customers can negotiate for longer term storage of engineering data as well as 
long term storage of payload data. The customer will have knowledge, by means 
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of an interactive terminal, of the contents of all archived data and the means 
to retrieve it with the exception of data that is protected for privacy 
purposes. In this regard, any customer may designate the level of privacy 
associated with the data, and through mutual agreement, allow other persons 
access to the data. Again, the level of post-mission support would be 
cost-dependent. 

4.4.2 Operator's Perspective of SSIS Operations 

SSIS operation is described in this section from the perspective of ground and 
onboard Space Station Program (SSP) operators. Operator is defined as either 
NASA or contractor personnel who manage, coordinate, and effect SSP operations 
and assist customers in accomplishing mission objectives. The operator's 
perspective is described through a set of operator tasks. These tasks range 
from system development to real-time operations. Section 5 provides 
additional information. 

Figure 4-25 provides an overview of operator's perspective discussed herein. 

EVA 

OMV Integration/ customer 



Figure 4*25. Overview of Operator's Perspective 
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4. 4. 2.1 Operator Background . Before the individual operator tasks are 
presented, the assumptions made for the operators' perspectives and a 
description of generic material that applies to all the operators is 
presented. These descriptions provide background material that may apply to 
one or more of the operator tasks and can influence the operator perspective. 

The generic material provides viewpoints or perspectives of what an operator 
should know about these subjects. None of the descriptions are specific tasks 
but concepts that influence operators' perspectives. This information enables 
the operator to understand the overall ground or onboard operational 
environment and/or scope of responsibility. At times, these descriptions 
touch on customer perspectives to give a clearer picture of the operator 
environment. The five areas cover 

1. Automation 

2. Work stations 

3. Redundancy/failure managemeht 

4. Privacy/security 

5. Standardization/commonality. 

The fifteen operator tasks are 

1. Hardware maintenance 

2. Software development and maintenance 

3. OMV, OTV, MMU, COP, and free-flyer control 

4. Oocking/berthing 

5. EVA 

6. Avionics management 

7. Non-avionics core system management 

8. Logistics 

9. Unmanned operations 

10. Safe-haven/contingency 

11. Facilities management 

12. Training and simulation 

13. Planning/scheduling 

14. Onboard mission support 

15. Customer coordination 
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• Operator data provided by standard communication services 

• Spacecraft hardware maintenance is primarily replacement. 

• COP is serviced from the Space Station 

• POP is serviced from the NSTS 

• Prime software development languages for the SSP will be a minimum 
set of standard High Order Languages (HOL's). Included will be a 

- "User Interface Language" for commands, displays, 
system test. 

• Space Station controls all operations within its control zone. 

• Constellation Operations: 

- Station remote manipulator for berthing/docking, 
deployment, station servicing. 

- OMV can grapple, maneuver OTV, COP, free-flyers 

- EVA's for COP, OMV, free-flyer servicing 

• SSCC provides global interfacility coordination 

• COP and POP control centers control platform operation 

• Planning and scheduling integrates core and customer requirements; 
all data/plans for flight and flight support operators contained in 
flight data file. 


4. 4. 2. 3 Generic Concepts. The six generic support considerations and 
concepts described in this section apply to all of the specific tasks 
performed by the operators. 


4. 4. 2. 3.1 Automation. The first viewpoint of any operator is to ask: what 

job or role must I fulfill? One major factor impacting the answer is the 
degree of automation of the system that will support the operator. The 
spectrum of automation ranges from a labor intensive, step-by-step manual 
control to attending to a system only when alerted by the system of a problem 
or need for interaction. The operator does not have to monitor a display 
unless there is a specific reason. Casual monitoring is possible but not 
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required. Certain safety aspects may require close-at-hand monitoring for 
specific operations to reduce the time for manual takeover, but this is a 
planned event. 

Table 4-5 presents a view of core and customer weekly manpower derived from 
data in the Phase B RFP (reference 1). The data shows the limited number of 
hours available per week for all operation activities, particularly for core 
operations. These data clearly show a limitation of onboard operator time 
availability. The automation and autonomy trade studies must consider this 
limitation for the autonomous, non-automated Space Station option in addition 
to other factors such as cost effectiveness and total program cost. 

The burden of onboard operator monitoring and management of core and customer 
systems can greatly be reduced by tutorial and prompting aids. Figure 4-26 
gives a view of an operator managing three displays. The cursor on the 
operators Daily Summary is positioned and the "enter" key is depressed to 
activate the Payload SAA XXX Plan display. After, "events" 1 and 2 are 
completed ("C" under status), the cursor is positioned to Event-3 and the 
Event-3 detailed display is activated. This display shows the operating 
status as active ("A") at Step-2 whose duration is 50 minutes. The 


Table 4-5. On-Orbit Manpower Availability in Man-Hours Per Week 


Activity 


Core Customer 

Support Support 


Scheduled 

Training 

Replanning 

Unscheduled 


48 (Note 1) 
6 (Note 3) 
6 (Note 3) 
6 (Note 3) 


264 (Note 2) 

18 (Notes 3,4) 
18 (Notes 3, 4) 
18 (Notes 3, 4) 


Total 


66 Hours 


318 Hours 


Notes: 

(1) 2 Space Station Operators x 4 Hrs/Operator x 6 Days = 48 

(2) Note (1) + 4 Mission Operators x 9 Hrs/Operator x 6 Days = 
264 


(3) Space Station Specialist Time for These Activities Divided 
Evenly Between Core and Mission OPS 

(4) Nominal Mission Specialist Time Spent Only on Missions 
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Figure 4-26. Prompts for Operator 


elapsed-time clock indicates 5 minutes and 10 seconds of activity into the 
Step-2 sequence. These types of aids are necessary to maximize efficient 
onboard operations and to minimize training time. 


In an effort to relieve the Space Station ground and flight operators of as 
many duties as possible, the promising potential of artificial intelligence 
(AI) will be considered. In addition to the more traditional automation 
techniques, full use will be made of the emerging capabilities of AI systems 
that perform such functions as: problem diagnosis, planning and scheduling, 

computer-aided instruction and training, data base storage and retrieval, 
voice recognition, natural language understanding, visual pattern recognition 
and robotics. IOC versions of these systems will generally tend to take the 
form of operator "assistants" rather than operator "substitutes". As 
confidence grows in the reliability of these systems, they will evolve toward 
more autonomous operation. 


The area of artificial intelligence with the most near-term promise is in the 
area of "expert systems". Very significant gains in operator productivity can 
be expected early in the program through the utilization of this technology. 
Potential SSP applications for expert systems are numerous and varied, and the 
production of these systems will yield a great deal of terrestrial benefit, as 
well as Space Station benefit. Some of the more obvious applications are: 
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diagnosis of problems in on-board systems, medical diagnosis, activity 
planning and scheduling, intelligent computer-aided instruction and training, 
and intelligent data storage and retrieval assistance. 


Figure 4-27 provides a brief summary of operators perspectives towards 
automation. 


DRIVERS 

■ Full-Time Operation 

■ Limited On-Orbit Resources 

■ Minimize Ground Army 

OPERATOR’S VIEW OF AUTOMATED OPERATION 

■ Normal Operations Are Automated 

■ Operator Notification When Action Required 

■ Prompts Operator 

• Level Choosen by Operator 

• Supports Training 

ARTIFICIAL INTELLIGENCE TECHNOLOGY 

■ Expert Systems Now Emerging 

■ Other Technologies for Growth 

• Voice Recognition 

Figure 4-27. Automation Is the Key to Effective Use of Operators 


4. 4. 2. 3. 2 Workstation. Workstations are generally viewed as multipurpose 
applications consoles (MPAC). These provide ground and onboard operators the 
necessary means to control and monitor the status of all SSIS functions. A 
portable MPAC is also available for flight operations at locations away from 
fixed MPACs . 

The basic characteristics performed by the MPAC are: 

1. Command and control (interactive) 

2. Multifunction (not dedicated to a specific task) 

3. Visibility into all SSIS functions 

4. Annunciation (alarms, caution, and warning). 
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The operations tasks are all accomplished by configuring a MPAC. A second 
MPAC can be configured as a backup to the prime MPAC. 

Workstations will also take other forms. Onboard windows will be used to 
monitor EVAs, exterior station operations (docking/berthing, vehicle relative 
motion, mechanism movements, and earth/celestial observations). Television 
monitors will be used extensively for IVA and EVA operations. OMV and RMS 
end-effectors and docking operations are some examples. Also, joystick 
control of the Space Station Mobile Remote Manipulator System (MRMS) is a 
special feature not part of the MPAC. Other special mechanisms for specific 
operations at various Space Station locations will be used. 

4. 4. 2. 3. 3 Redundancy/Failure Modes. The Space Station and platforms will 

have a wide variety of redundancy management methods employed in the 
implementation of the ground and on-board systems. Those ground parts of the 
data system which do not provide real-time support are expected to be simplex, 
with repair as the failure recovery technique. Any ground data system 
components which support real-time operations may, in addition, include 
redundancy in the form of on-line (hot backup) equipment ready to take over 
immediately, or in the form of off-line (cold backup) equipment that can be 
reconfigured in a short time for real-time support. In both cases, the 
current configuration will be available as a checkpoint from which to restart, 
without the need to manually respecify the entire system configuration. 

The onboard subsystems may require a wider variety of redundancy options, due 
to more limited repair and replacement capability. Those portions of onboard 
data critical to the operation of the spacecraft and to the well-being of the 
crew (Space Station) will employ redundant on-line subsystems, executing in a 
fail-operational/fail-safe (FOFS) configuration. Those portions of the data 
system requiring recovery in a few seconds may utilize an on-line, 
reconf igurable spare in a failure mode. Less critical portions that allow a 
few minutes of down time, may be implemented as one on-line unit with an 
alternate unit connected to the system but with power removed. This cold 
backup technique allows recovery by manually or automatically turning off the 
faulty unit and turning the replacement unit on. The faulty unit may then be 
repaired or replaced from the spares. For subsystems which allow extensive 
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periods of down time, ranging from a few minutes to several hours or days (or 
until the next NSTS visit, in the case of the POP(s)), there may be a single 
unit connected to the system. In case of failure, this unit would be repaired 
or replaced from the spares before being restored to normal operation. 

Finally, for the least critical subsystems, where loss is very unlikely and is 
not critical to safety or to the mission, there may be no spare or repair 
capability on-board. 

The operator may be involved in implementing portions of any of these 
redundancy methods. The operator will be especially involved in directing 
system fault down when system capability must be shed because of failures, in 
fault isolation and recovery, and in repair. The exact technique to be used 
will depend on the subsystems which are defined as the system design is 
developed. Key considerations in arriving at the redundancy levels will be 
the criticality of the subsystem, the likelihood of subsystem failure 
(including the probability of multiple failures between the NSTS revisit 
points), the sparing level (subsystem, units, components, etc., including 
online spares on the platforms), the ease of replacement or repair (especially 
if EVA is necessary), and the storage space available for spare parts. 

4. 4. 2. 3. 4 Privacy/Security 

Privacy and security (definitions) of data and communications will be 
needed within the data system to prevent unauthorized access to customer's 
data bases, payloads and operations procedures. Security requirements may 
include the resource utilization profiles of some payloads. These needs must 
be balanced with the need for safety of the vehicle and crew and for the 
control of interaction among the vehicle and several payloads. 

The three basic parts of privacy provided by the data system are the ability 
to command a payload or core function, the ability to passively listen to 
communications, and the ability to read out stored data and procedures. 
Commands to the payloads must be checked for authorization of the operator to 
command that payload. Further measures must be provided to assure a high 
degree of security and privacy of data, such as that contained in on-board or 
ground data bases and of data transmissions. The data system will include 
normal commercial protection techniques such as password protection for access 
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to data bases. All transmissions of data will be encrypted. In addition, the 
individual customers may apply their own data encryption within the data 
itself for further security and protection against "tapping" the communication 
links. The data required for interactive planning and scheduling must also be 
protected from general access to avoid inadvertent compromising of proprietary 
processes. The only constraint imposed by the data system on individual data 
encryption is that any information needed for routing data within the data 
system must be in the clear. For example, the identification of the 
destination of the communication, the identification of the sender, and 
adequate information to distinguish restricted and constrained commands must 
be in the clear. 

4. 4. 2. 3. 5 Standardization/Commonality. Standardization can lead to 
increased human productivity and reduced program life-cycle costs and 
therefore will be used extensively on the Space Station Program. The concept 
of standardization can have different meanings. Standardization can mean a 
common element used widely within a program, but this element may not be 
common with any other program. It can mean commercial or military standard 
specifications or discipline organization standard specifications for 
communications interfaces, network protocols, processor instruction 
architectures, etc. Standardization will be incorporated into the Space 
Stations program in some or all of the following forms: 

1. Space Station program defined standards 

2. Commercial standards 

3. Military standards 

4. Discipline organization (e.g., IEEE, SAE). 

These standardization issues will be the subset of a Task 3 trade study to 
determine the level and vigor with which standards will be employed. 
Commonality on the Space Station Program (SSP) means use of the same equipment 
and software across Space Station Program Elements (SSPEs). That is the use 
of standard or common hardware and software systems for Space Station, 
Co-orbiting Platform, Polar Orbiting Platform, OMV, OTV, etc. As such, 
commonality could be considered a higher level of standardization applied at 
the program level. 
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Standardization will be used extensively for application in the SSP and in 
SSDS. Standardization will be implemented for: 

1 . Oata Distribution 

- network protocols 

- network operating systems 

- inter-networking 

2. Software languages 

- user interface language 

- applications language 

3. Operating Systems 

4. Data Base Management Systems 

- query language 

- data organization 

5. Packet telemetry and telecommands 

6. Processors 

- embedded microprocessors 

- general purpose processors 

- network interface units 

7. Multi-purpose Application Consoles (MPAC) 

8. Software development approaches/tools. 

All of these areas are transparent to the operator except the various 
languages (user interface, applications, DBM query), the MPAC and the software 
development approaches/tools. 

The International Standards Organization (ISO) seven layer reference model for 
Open Systems Interconnect (OSI) is not a fully accepted standard, but current 
and future implementations will greatly influence future standards. 
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The following operator interface scenario describes the standardization level 
that will be realized on the SSP. The operator interfaces to the SSOS through 
a standard MPAC. The fixed and portable MPAC are functionally the same. The 
operator has worked on a standard MPAC during ground training and simulation 
and knows the Logon procedures and how to select options from menus. Standard 
aids are available which present "help" displays which the operator has seen 
before and during training. 

Changing or creating software in the space environment is the same process as 
the operator uses on the ground. The applications language and user interface 
language are the same and the software editor is the same. All the procedures 
for changing or creating software are the same. The onboard operator will be 
able to address software created off-line and make desired corrections. 
Simulation support to validate and integrate new software will be available. 
Protection will be provided to inhibit inadvertent or unintentional changes to 
flight critical software. The flight-critical software development is a 
ground process. The standard user interface language allows any operator to 
create and execute test control sequences. However, coordination is required 
if test control sequences cross some core subsystem and customer payload 
interface boundaries. 

The technique for requesting hard copy of displayed data is the same on all 
MPACs. Each display panel used for subsystem control presents a unique 
layout, but typically items such as the keyboard layout and touch screen 
control will be standard. 

The operator has a standard data base query language. The query language is 
the same as that used on the ground for inventories, manuals, schedules, 
maintenance, etc. The physical location of the data is transparent to the 
operator. 

Growth and technology insertion are both very strongly tied to 
standardization. For example, growth in data processing can be achieved by: 

(1) adding more processors to a system to provide additional capability, or 

(2) replacing the entire subsystem with new technology. In either case, the 
interface standards between the new change (processor, software, sensors, 
devices) and the existing systems must meet established standards. 
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Software improvements can be particularly expensive in an embedded system 
unless pre-planned improvements were accounted for in the initial designs. 
Again, interface standards must be met. 

Operator perspectives for these improvements could range from no impact to a 
direct impact. Direct operator impacts are those that involve: (1) defining 

the change, (2) implementing the change, or (3) new training because of the 
change. 

Figure 4-28 provides a summary of standardization/commonality with respect to 
simplification of operations. 


■ Ground to Onboard 

• Training to Operations 

• Maintenance 

■ Throughout Space Station Program 

• Core Systems 

• Customer Systems 

• Standard Customer Services 

■ Operations Transparency 

• Growth 

• Technology insertion 

• Changing Mission Set 

• Data Handling 

Figure 4-28. Standardization/Commonality Will Simplify Operations 

4. 4. 2. 4 Operator Task Descriptions . The following sections describe fifteen 
operator tasks that encompass the onboard and ground SSIS functions. This 
approach allows an across the SSIS functions view to provide a perspective of 
the SSIS through the separate operator tasks. The viewpoints generally 
represent mature operations. NSTS operations in support of the Space Station 
Program are not emphasized. 
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The individual operator tasks may provide views that range beyond the 
boundaries of SSIS. As such, the task scenarios were developed for 
completeness and general understanding of task activities. 

4. 4. 2. 4.1 Hardware Maintenance. This operator task consists of maintaining 
hardware associated with the Space Station and co-orbiting platform payload 
and core systems. The hardware is the set of data management equipment and 
subsystem devices. The hardware is distributed among the ground, the 
platform and the Space Station. Therefore, the operators are physically 
located in space and on the ground. 

The hardware operator task involves the following 

• Observation of equipment performance degradation or failure 

• Isolation of the problem 

• Determination of what action, if any, is necessary 

• Scheduling the maintenance 

• Performing the maintenance and retesting. 

This operator task is accomplished by using the functions of device management 
and monitor and status. Device management is a generic function that enables 
the operator to manage and control the hardware and devices associated with a 
specific function group. For example, device management covers the devices 
associated with navigation. These devices could include star trackers, rate 
gyros, and alignment sensors. Device management allows the operator direct 
control via an MPAC over typical subfunctions for each device such as 

- performance monitor 

- redundancy management 

- configuration management 

- power distribution. 

The performance monitor subfunction is intended for a detailed health and 
status of the device. Monitor and status system is a global view of the 
health and status of the subsystems. 
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Generally, monitor and status system provides the operator with the first 
indication of a problem in a subsystem. System status provides this global 
service. This function would indicate which subsystem is affected and how to 
access the subsystem device management display for more detail. "Caution" and 
"Warning" may actually provide the first indication of a failure if the 
failure warrents an audio and/or visual alarm. Diagnostics support will be 
used by onboard and ground operators to provide more detailed support in 
determining the exact cause of the failure or isolating the failure to an 
Orbital Replaceable Unit (ORU). Schematic presentation, expert systems and 
trend analysis support will be available to the operators. Command interface 
processing will be a software process that implements the operator MPAC input 
commands to control any function group. 

In summary, the device management functions in conjunction with the monitor 
and status system function allow onboard and ground operator capability to 
perform the overall hardware maintenance task for ground and Space Station 
equipment. 

4. 4. 2. 4. 2 Software Development and Maintenance. The perspective of this 

task depends on the specific type of software to be developed. Software 
development will be performed for 

1. Onboard operating system and network operating system 

2. Onboard application software 

3. SSPE software: OMV, OTV, Core 

4. Optional support for customer software development 

5. Ground operations support sites: SSCC, COP-CC, POP-CC, DHC, RDC, SSE 

6. System test and control - generic 

7. User displays. 
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Another aspect of the problem is the specification of the language or 
languages a software developer would expect to use. 


Figure 4-29 illustrates the software development operator's viewpoint of the 
SSE. 



Figure 4-29. Centralized Coordination Is Required for Distributed Software Development 


The Software Support Environment (SSE) presents a perspective that is 
essentially the same for all software developers. The Phase B RFP goal is to 
use the SSE for all onboard and ground software development and maintenance 
for each flight Space Station Program Element (SSPEs) and for their ground 
support functions. Another Space Station program objective is to maximize 
commonality of hardware, software and systems among the SSPEs. "The SSE is 
defined as the common software required for the development of application 
software for the flight and ground systems." The exact SSE will be under 
study during the Phase B period. The SSE provides capabilities which supports 
the development facility discussed in 4.4.2.4.11. The following is a sumnary 
of the SSE scope. 
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a) Language processors — compilers, interpreters, preprocessors, 
assemblers and link editors. 

b) Simulators -- for design, development, test, validation and secondary 
training. 

c) Data Base Management Systems — storage and access of large set of 
data. 

d) Requirements and Design Tools — requirements development and program 
design languages. 

e) Test and Analysis Tools — simulation aids and data reduction 

f) Build and Delivery — integration of software components into 
program-end-items. 

g) Operating Systems -- standard network operating system and standard 
subsystem processor operating system for onboard SSDS. 

h) User Interface Language — a standard language for core and payload 
operators. 

i) Software Quality Assurance and Configuration Control Standards — 
follow NMI 2410.6 for all software development. 

j) Business Support Systems — all support tools must be consistent with 
the TMIS. 

The above SSE scope is today's best perspective for Space Station Program 
software development. However, all program elements may not be compatible 
with these concepts. For ground facilities, we must consider that NASA 
institutions currently contain millions of lines of development and 
operational software that support various space programs. The potential to 
recover much of the existing software base for Space Station Program 
utilization will be traded against developing and integrating new software 
based on program standards. It is anticipated that the ground systems will 
continue to reflect a mixture of commercially available program product 
software, NASA and DoD space program developed software and uniquely developed 
software for Space Station Program. 

A language utilization perspective for the various Space Station Program 
software users is presented in Table 4-6 The table is based on several 
assumptions, one of which is that a standard "higher order language" (HOL) 
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will be adopted as the primary method for software implementation. This does 
not preclude the customer from using non-HOL source language as an embedded 
element in the payloads but it will not be supported by the SSE. The payload 
software must then only satisfy the required, standard interfaces to the 
subject SSPE. 


Table 4-6. Software Development Language Development 


Software 

development 

type 

Languages 

Standard 

HOL 

User 

interface 

language 

Other 

language(s) 

Onboard operating system 

x 



(SS, COP, POP) 




Network operating system 

X 



Core applications 

X 

X 


Payload applications 

X 

X 

X 

OMV and OTV 

X 

X 

X (Note) 

SSCC, DHC, RDC, SDE 

X 

X 

X 

System test and control 


X 


User displays 


X 



Note: Allows for the potential use of existing flight-qualified embedded processor hardware and software. 


The User Interface Language (UIL) is viewed as the prime operator language to 
perform system testing and control. This applies to all SSPEs including the 
Space Station Program ground and onboard elements. As indicated in the table, 
UIL is viewed as the language that is utilized by all operators to build all 
system displays and by any operator to build special displays for viewing 
desired data. Also, UIL is used by all operators to build commands to acquire 
data and to send commands to Space Station systems, ground and onboard, and 
for customer payloads. Again, this does not preclude the payload operator 
from embedding pre-stored commands that are envoked by onboard operators or by 
standard customer interfaces. 
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The need for other languages is indicated in the table. These cover the 
discussions presented above with respect to the payloads, the OMV and OTV, and 
special ground operating systems, and existing institutional software programs. 

The SSE, the above language view, and NASA controlled software development 
procedures provide a perspective of software development. Operator developed 
procedures must follow NMI 2410.6 for all software development. 

4. 4. 2. 4. 3 OMV, OTV, MMU, COP and Free-Flyer Control. A background overview 
for the constellation elements operations described in this and the next 
section allows the Space Station to be used as an effective base of 
operations. In summary, it allows: (1) a variety of environments, (2) extend 

the range of man's operation, (3) extends system life, and (4) provides a base 
for higher energy missions. 

The general operator tasks associated with these five vehicles in association 
with the Space Station are: 

1. Maintain and service 

2. Deploy 

3. Control within Space Station control zone 

4. Control outside Space Station control zone 

5. Retrieve. 

Task 1 is performed by onboard or ground operators. Tasks 2, 3, and 5 are the 
responsibility of onboard operators. Task 4 is a ground responsibility and is 
not in the SSDS. The preceding applies to the OMV, OTV, and COP. The MMU is 
controlled only by onboard operators. All operators can utilize an MPAC to 
achieve these tasks. All five tasks are achieved by managing operator input 
commands/data and basic operation of the core systems. 

Task 1 Maintenance and Service, is accomplished by using the functions which 
support customer system operations, operate Core subsystems and basic crew 
support. The OTV, OMV, and MMU maintenance operations are performed jointly 
by onboard and ground operators. The service and maintenance of the COP and 
free-flyers are both treated as payloads and are achieved by operator 
interaction with functions which support customer payload checkout/service. 
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Any vehicle, while attached to the Space Station, can receive standard 
services. These are: power, thermal control, structures and mechanical 

support, communication, and external interface management. The platform is 
serviced by EVA or robotic operations, either on site or retrieved and 
attached to the Space Station. EVA may be based on the Space Station or the 
Shuttle Orbiter, while robotic operations may be controlled from the ground, 
the Shuttle Orbiter, or the Space Station. 

Task 2, vehicle deployment from the Space Station, is achieved by onboard 
operators. The Space Station MRMS is likely to be used for deployment of most 
vehicles from the Space Station. The HMU is deployed by EVA operators. The 
MRMS operator would impart sufficient relative velocity to avoid recontact. 

The onboard operators could deploy the OMV by directly controlling its 
translational capability. This depends on safety and environment 
contamination considerations. The same could apply to the OTV. Another 
option is, once the OMV is free it could be controlled by the onboard 
operators to grapple and then deploy the vehicle (OTV, f ree-f lyers) . 

Automatic deployment by the MRMS may be a possible operator selected option. 

For task 3, control within the Space Station zone, the onboard operators will 
generally control the attitude and positioning of all vehicles. This will be 
accomplished by transmitting relative position and attitude commands to 
constellation members. Those vehicles without guidance, navigation and 
control functions (free-f lyers) will be placed and repositioned by operators 
controlling the OMV. Vehicles in the constellation will be maintained in a 
basically coplanar orbit with the Space Station. Position monitoring and 
traffic control will be highly automated functions. Approach and departure 
corridors will be kept clear to allow access to the control zone. 

Vehicles such as the OTV, OMV, and COP may leave the control zone and thus 
require ground operator control. These vehicles are returned to the zone by 
rendezvous sequences controlled by ground operation centers (Task 4). The 
desired return point for entry to the proximity sphere is defined by the Space 
Station traffic control function. Control handoff after rendezvous completion 
is accomplished automatically by traffic control command to the cooperating 
vehicles (OTV, OMV, COP). One transfer option is for traffic control to 
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command the cooperating vehicle to maneuver to a zone reachable by the Station 
MRMS (except COP). Another is to have the OMV maneuver the vehicle to the 
MRMS reachable zone. When the MRMS has grappled the vehicle, traffic control 
discontinues active control. 

Task 4, control of vehicles outside the Space Station control zone are the 
ground operator's responsibility. These are not discussed in detail. 
Operations include: (1) maneuvering the OTV, OMV, and COP to and from the 

Space Station control zone, (2) platform operations, (3) OTV missions, and (4) 
free-flyer operations. 

Task 5, the retrieval of a vehicle in the Space Station control zone, is 
achieved by onboard operators. The OMV is maneuvered to the docking/berthing 
position along a safe return path. The safe return path is determined by 
using traffic control for all approach trajectories. The OTV may be 
maneuvered to the Station by onboard operators, or the OMV may be used to 
retrieve the OTV. The MMU can be maneuvered by the EVA operator to the 
Station MMU attach point. The COP is brought near the Station by the OMV for 
EVA servicing. 

4. 4. 2. 4. 4 Docking/Berthing. Oocking/berthing is likely accomplished with 

the use of the Station MRMS. It is basically the reverse of deployment. 

Video cameras are used to monitor and an MPAC. is used to manually control the 
operation. The RMS operation could be highly automated; automatic deployment, 
storage and way point maneuver sequences, collision avoidance from known 
configuration, video on end-effector, automated grappling and rigidizing 
sequences. The operator could invoke these automated sequences and supplement 
them with manual RMS control to berth the COP, OMV or free-flyer. Final 
alignment, retraction, capture latching, and rigidizing may be done by 
automated sequences, monitored and controlled by the operator. The MMU is 
attached by the EVA operator. The free-flyers are attached to a maintenance 
position by the RMS or EVA operator. 

The NSTS can dock to an unmanned Space Station or be berthed at a manned Space 
Station. If the Space Station is manned then there is audio contact between 
the NSTS and Space Station operators. The NSTS crew also has visual contact 
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with the docking port during final approach. The Space Station operator 
requests the NSTS to be placed in a free drift manual mode before the RMS 
grapples the NSTS for berthing. If the Space Station is unmanned, then the 
docking is controlled by the NSTS. 

4. 4. 2. 4. 5 EVA. The operator monitors EVA using video support and audio 
communications to MMU or EMU. An MPAC is configured to monitor and control 
airlock activity. Automated sequences (with manual override) are used for 
environmental conditioning of the airlock and control of airlock access 
(opening, closing, latching). Manual overrides are provided for all these 
automated functions. Monitoring and control of the MMU is performed 
autonomously by the EVA operator and station operators. The RMS can be used 
to position the EVA operator for Station and vehicle service operations. The 
platform will be serviced by EVAs. The OMV can maneuver the COP platform 
within the MMU/EVA range for serving. The platform itself may be maneuvered 
within servicing range. POP EVA activities and capabilities are described in 
JSC 07700. 

4. 4. 2. 4. 6 GN8«C Management. The avionics systems are highly automated and 
are designed to require minimal attention by operators to continue proper 
operation. The avionics systems include navigation, guidance, attitude 
control, traffic control, tracking and time management. These systems are 
self-managing and perform automatic reconfiguration to recover from failures. 
Manual override is provided. 

The operator interfaces with each of these systems by configuring an MPAC by 
selection from system menus. The operator is aided with prompts. Systems 
performance and status is displayed at the MPAC. Graphics is used as much as 
possible to present data. When failed ORUs are replaced and demonstrated to 
be operational by self-test, the operator uses the MPAC to inform the avionics 
system of this restoration. The avionics system then automatically 
reconfigures the redundancy management level. 

The operator has the capability to override or inhibit automated functions 
using the MPAC. 
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Many avionics systems are automatic with minimal operator interaction. The 
operator interacts with mission planning to coordinate reboost. Momentum 
management is automated. The nominal Space Station attitude is an earth 
reference local vertical. The operator can select and effect various attitude 
orientations from the nominal. Any attitude maneuvering is performed 
automatically after the attitude reference is established. 

The navigation functions of attitude and state vector determination are 
performed automatically. This includes filtering, sensor source selection and 
source editing. The operator has override capability. The operator interacts 
with traffic control to coordinate OMV activities required to reposition 
free-flyers in the constellation. The operator also manages collision 
avoidance option selection. Time and frequency management is automated using 
GPS signals. 

4. 4. 2. 4. 7 Non-GN&C Core System Management. The operator manages the core 

facility subsystems using automated sequences supported by the MPAC. The core 
facility subsystems include: power, thermal control, structures and 

mechanisms support, ECLSS, communications, and external interface management. 
All core facilities operate automatically with minimal operator attention. 

The operator monitors and controls the core facilities subsystem in a similar 
fashion to the avionics systems. The main operator interactions are to 
monitor status and performance and to restore redundancy following replacement 
of failed ORUs. 

The operator interacts with the communication subsystem to establish voice and 
video contact internal to the Space Station and with external vehicles. The 
operator also configures the communications subsystem to establish voice and 
video contact with the MMU for EVA. 

4. 4. 2. 4. 8 Logistics. The primary onboard operator interface with the 
logistics system will be to update the status of inventory items not monitored 
automatically. These data are input to the integrated logistics function for 
resupply and inventory management, using methods similar or the same as 
commercial inventory managers and resupply. While some spare parts and 
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supplies will be monitored automatically, most will require the onboard 
operator involvement in entering identification of failed parts and spares and 
supplied used. 

The ground operator may have a much wider involvement, in that some aspects of 
inventory control and transportation may be cost effective as manual or 
interactive operations. 

4. 4. 2. 4. 9 Unmanned Operations. The Space Station is intended to be a manned 
operation after initial build-up, except in unforeseen circumstances that may 
require removal of the crew. In such a case, the vehicle will be made 
quiescent, with only safety critical core and/or payloads operating. There 
will, of course, be no onboard operator. The ground operators will assume 
responsibility for all operations during unmanned phases. Nominally, the 
operator should need no special functions beyond his normal monitoring 
functions, since the onboard subsystems are automated and operate 
autonomously. In the event of a failure or the need to activate or deactivate 
a subsystem, the ground operator will use the normal telecommunications to 
perform the needed actions to monitor and control the onboard systems. 

4.4.2.4.10 Safe Haven/Contingency. This operator task involves those 
functions of the data system needed to operate the safe haven in contingency 
conditions, such as loss of pressurization or damage to a module. The basic 
assumption is that there will be the need for an orderly shutdown of 
non-critical core and payload functions, and for a more frequent monitoring of 
remaining levels of resources, such as food, water, and other supplies. 

The safe haven/contingency operator tasks include the following: 

1. Monitoring supply levels in the safe haven. 

2. Safing or orderly shutdown of non-essential subsystems and payloads. 

3. Correction of the malfunction, if possible. 

4. Resumption of normal operations after correction. 

5. Docking and rescue from the safe haven, if appropriate. 
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These operator tasks make use of several functions. The generic function of 
device management, necessary for safing and orderly shutdown, is exercised 
from the workstations in the safe haven by the onboard operator, or from the 
telecommunication link by the ground operator. 

At any time, the ground operators can take over onboard operator's systems 
management tasks, if necessary, during contingencies. 

4.4.2.4.11 Facilities Management. This core operator perspective covers 
several viewpoints: 

1. A physical location and means to accomplish an operator task. 

2. A location to status all high level aspects of a facility. 

3. A location to access detailed data from distributed facility sources. 

4. A location to command and control distributed facility functions. 

5. A location for coordination of separate operational requirements into 
an integrated operational plan. 

These five tasks can be grouped in two basic sets. The first set is task 1 by 
itself. The second set is the rest of tasks 2 to 5. Task 1 is the view that 
facility management is the means to do the job. The second set is a view for 
the operator whose job is basically to either directly support the operators 
under task 1 or manage/control the specific facility so that the operators 
under task 1 are successful. The "facilities" in this report are: 

- Space Station Flight Facility 

- Space Station Control Center (SSCC) 

- Regional Data Center (ROC) 

Data Handling Center (DHC) 

Development Facilities (includes SSE). 
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The subfunctions under "Manage SSOS Facilities", describe the activities 
associated with these five facilities. All of these facilities are used by 
both core and customer operators. This section provides a core operator 
viewpoint. 

Table 4-7 provides a perspective of facilities management for each individual 
operator task in 4. 4. 2. 4. This table is a task 1 viewpoint of what each 
facility provides as a means to accomplish each operator job. 

Tasks 2 through 5 are partially described in the table. However, these tasks 
are much more detailed at each facility level. They cover the day-to-day and 
long term management of each facility. 

The flight facility is managed by both ground and onboard operators when it is 
manned. Onboard, the generic device management and operate core systems 
function, are used to achieve detailed reviews of system performance, 
individual device performance, and subsystem performance and status. Most of 
these tasks will be automated in the mature operations phase. More hands-on 
monitoring and control will be needed prior to this time. Global management 
of all onboard systems and necessary customer systems management (basic 
operations and safety information) will be achieved by interfacing with the 
"Monitor and Status System" function set. The SSCC provides basic onboard 
operator support and will manage separately, specific onboard elements. The 
ground also provides basic "second source" data and commands for element 
failures and contingency needs. For extreme contingencies, the ground 
operators at the SSCC, may take over most of the Space System system 
management. For normal operations prior to the "mature operations phase", the 
ground will receive more telemetry to monitor and control the planned 
operations. Much less telemetry will be needed for the mature operations 
because of increased onboard automation onboard reports if system status and 
operation will be prepared and downlinked. In addition, the capability to 
increase the detailed view of any onboard system through increased telemetry 
will be available and easily invoked by ground operators. The unmanned 
operation by SSCC operators may require less telemetry for habitable systems, 
but again, for special needs the ability to acquire any system and control 
that system will be easily implemented. 
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The SSCC operators must also manage SSCC ground operations and also provide 
global interfacility coordination and planning. These detailed operations are 
not detailed herein. Tasks 1 through 5 and the "views" in Table 4-8 provide 
some insight. In general, the parallels between the flight facility 
management and the SSCC management are very strong. Both must manage: (1) 

distributed functions in physically separated systems, and (2) personnel 
assignments and coordination in widely separated locations. 

The ROC and DHC management needs are indicated by their functions and in Table 
4-7. The management needs of these facilities again parallel the SSCC general 


Table 4-7. Operator Facility Perspective 



Facility applicability 




Regional 

Data 




Space Station 

data 

handling 


Operator 

Space 

control center 

center 

center 

Development 

task 

Station 

(SSCC) 

(RDC) 

(DHC) 

facility 


H/W 

maintenance 

• Hands-on 

• Performance 

• Inventory 

• Self test 

• Replace 

• Short term trend 

• Performance 

• Inventory 

• Diagnostic 

• Schematics 

• Expert system 

• Long term trend 

• Contractors 

Same as 
SSCC 
for RDC 
functions 

Same as 
SSCC 
for RDC 
functions 

• H/W sim 

• System test 
(H/W, S/W) 

• Trouble analysis 

• T raining 

S/W 

development 

and 

maintenance 

• Display gen. 

• Develop some 
test scripts 
(test lang) 

• No source language 
S/W dev 

• Test scripts 
(test lang) 

• S/W dev 

• Display gen 

Same as 
SSCC 
for RDC 
functions 

Same as 
SSCC 
for DHC 
functions 

SDE for all 
application 
S/W dev 

OMV, OTV, COP 

free-flyer 

control 

• Hands-on 

• S.S. control zone 

• OMV control 

• OTV control 

• COP control 

• S.S. RMS 

• Outside 

• S.S. control zone 

• OTV control 

• Coordination 
(COP, OTV, OMV) 

• SSST training 

N/A 

Vehicle data 
TLM handling 

• Simulation 

• Secondary 
training 

Docking/ 

berthing 

• Hands-on 

• All vehicles 

• Monitor/control 

• S.S. RMS 

• Cooperative 
NSTS docking 

• Monitor 

• Support 

• SSST training 

N/A 

Vehicle data 
TLM handling 

• Simulation 

• Secondary 
training 

EVA 

• Hands-on 

• Monitor 

• S.S./Vehicle 
servicing 

• Monitor 

• Support 

• SSST training 

•N/A 

TLM handling 

N/A 

Avionics 

management 

• Hands-on 

• Monitor 

• Control 

• Monitor/Perform. 

• SSST training 

• Control support 

• Diagnostics 

• Expert system 

N/A 

TLM handling 

• Simulation 

• Secondary 
training 

• S/W dev 

Non-avionics 
core system 

Same as above 

Same as above 

N/A 

Same as above 

Same as above 

Logistics 

• Sparing 

• Logistics module 

• Inventory 

• Center logistics 

N/A 

N/A 

N/A 


• S.S. support 
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Table 4-7. Operator Facility Perspective (Continued) 



Facility management 


’ 


Regional 

Data 




Space Station 

data 

handling 


Operator 

Space 

control center 

center 

center 

Development 

task 

. Station 

(SSCC) 

(RDC) 

(DHC) 

facility 

Unmanned 

N/A 

• Management of all 

N/A 

Reduced TLM 

Continue normal 

operations 


core systems 
• Reduced SSCC ops 



functions 

Safe -haven 

• Occupy area 

• Contingency support 

N/A 

• Normal TLM 

• Contingency 


• Reduced ops 

• More onboard ops 


• Special TLM 

support 


• Contingency train. 

mgmt 


needs 

• Continue normal 


• Contingency flight 




functions 


data file 





Training and 

• Station specialist 

• SSST training 

• RDC training 

• DHC training 

• Normal ops 

simulation 

• Mission specialist 

• SSCC ops 

• RDC simulation 

• DHC simulation 

• All operators 


• Health and habitat 

• Global mgmt 



• Contingency 


• Infrequent events 
■ Contingency 

• Contingency 



• Sim support 

Planning and 

• Near term updates 

• Near term coord 

• Plan 

• Plan 

• Normal ops 

scheduling 

• Long term access 

• Long term dev. 

• RDC train 

• DHC train 

• Contingency ops 


coordination 

• Intercenter 

and sim 

and sim 



• Flight data file 

coordination 





access 

• Flight data file 





• Contingency 

mgmt 

• Contingency 




Onboard 

• Prime support 

• Normal ops 

• POCC role 

• Normal ops 

• Normal ops 

mission 

to customers 

• Customer support 

• Customer con- 

• Special 

• Sim support 

support 

• Station specialist 

• Global mgmt' 

trol options 

customer needs 

• SW dev (optional) 


backup 


• Customer/mission 




• Multi-tasked 


specialist 




among customers 


coordination 



Customer 

N/A 

• Normal ops 

• POCC 

• Normal ops 

• Normal ops 

coordination 

(ground) 

• Customer/mission 

• Customer con- 

• Customer/ 

• SW dev 



specialist 

trol options 

specialist needs 

coordination 



coordination 

• Customer/mission 

coordination 

• Sim support 



• Global mgmt 

specialist 

coordination 




4.4.2.4.12 Training and Simulation. This section covers the training and 
simulation needs of COP operators in the Space Station and ground operators 
for the POP and COP. It does not cover those same needs* at the Data Handling 
Center (DHC) and at the Regional Oata Center (RDC) . The discussions do cover 
the needs of the Space Station. Control Center (SSCC), the SSE, the customer 
facilities and the flight facilities. Training is defined as all the 
information and Interactions necessary for an Individual to perform a task. 

This can include "built-in simulations" that are envoked by the operator 
interactions. Other simulations are controlled by operators that are 
examining detailed data to determine system element correctness or 
performance. These latter simulations are typically performed by software 
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development and system testing personnel and are not considered operator 
training herein. Lesser training fidelity is required for the Space Station 
than in past programs because of increased system automation. 

Figure 4-30 provides a view that training and simulation maximizes SSP 
operational capabilities. 


Training of flight operators is achieved by interaction with onboard and 
ground facilities. The ground training elements of the SSCC are: 


- Space Station Systems Trainer (SSST) 

- Proximity and manipulator operations trainer 

- One-g trainer 

- Flight environment trainer 

- Training terminals. 


Operator training is achieved through "part -task" training and "full-task" 
training. The part-task training is focused on smaller tasks. Full-tasking 
training joins part-task elements into a higher-level of fidelity necessary 
for integrated training. 



Figure 4-30. Training and Simulation Maximizes Use of Program Operational Capabilities 
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The SSST provides both part-task and full-time task training. This includes 
system management (avionics and non-avionics), system management ground 
support, activity planning, logistics, communications usage and 
contingencies. It provides a representation of the operating environment of 
the manned modules. The SSST will be networked to the other ground training 
elements as needed. 

The proximity and manipulator operation trainer provides part-task operator 
training to develop hand and eye coordination and precise control. The 
manipulator is used for berthing/docking, grappling structures, and payload 
deployment. This high-fidelity training contains controls, displays, visual 
cues and dynamics. The trainer can be interfaced with the SSST and NSTS crew 
simulator as necessary. The trainer also contains a high-fidelity OMV 
simulator of its maneuver capabilities and it manipulator operation. 

The one-g trainer will be kept in the same configuration as the Space Station 
and provides training for habitability, maintenance/service and EVA 
preparation. 

The flight environment trainers provide a neutral buoyancy trainer, hardware 
mockups and tools for activities in a weightless environment. 

Training terminals will be available (MPACs) that are the same as those in the 
SSST that provide tutorial walk through training. These relieve the training 
load on the SSST. 

Preflight training for Mission Specialists and customers is a ground 
reponsibility. These ground operators are tasked with the training of these 
two sets of people to operate in the Space Station environment. POCC training 
is provided at the POCCs. The customer facilities are used extensively for 
onboard (Mission Specialists) and ground operator/customer payload training. 

Training on the Space Station will essentially take place on the job. 
Experienced crew members will train new crew members. The Space Station, 
obviously, contains the highest training fidelity. The operators will have 
interfaces to onboard data bases that contain information on schedules, 
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activity plans, maintenance and operations. All these data are available via 
an MPAC. Tutorial information on basic and detailed operations for onboard 
training and refresher training needs are available. 

The above are the prime training viewpoints. The Software Support Environment 
(SSE) is considered a secondary training facility and a prime specific 
simulation facility. The SSE training aspect may provide more fidelity in 
some cases than the ground facilities. These will be used as needed. 


The SSE presents to the operator not only a software development facility but 
a facility to perform simulations and secondary training. The operator 
controls simulations and training sessions from a standard MPAC, the same MPAC 
used for software development and for the onboard SSOS Interface. The SSE 
simulation capability has several major modes: flight simulation mode and 

flight computer mode. These modes are selectable by the operator. The flight 
computer mode is supported by hardware elements. These hardware elements are 
used to support the prototype concept. Customer supplied hardware can also be 
integrated into the simulation in the flight computer mode. The SSE always 
contains a full-up flight computer mode (network, processors, interface 
devices, secondary memory, etc.). The SSE has a network connection to the 
NASA Advanced Development DMS test bed for exchange of application software 
and models. 

The use of the SSE for simulation and training is supported by documentation 
in the form of user guides. These user guides are available on the MPAC or in 
manuals. Remote ground and onboard workstations (MPACs) are supported. The 
user guides contain various MPAC capabilities for selecting options in the 
simulation or training session. The operator is aided with "help" displays, 
prompts and illustrative examples. The test scripts developed for a session 
may be saved and used in subsequent sessions. The operator language for test 
script development contains as a subset a user Interface language. The user 
interface language is used during operations to construct test sequences and 
can be used for the same purpose during simulation or training. 

The SSE will support real-time training sessions and training in either the 
flight simulation or flight computer mode. Simulation runs will normally be 
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submitted by the operator for batch execution. These runs can be submitted 
remotely. Interactive simulation can be performed by the operator by 
uploading the simu-lation configuration to their remote workstation. Remote 
site training is supported but not in real time. Real-time remote site 
training can be accomplished by uploading the simulation configuration to the 
remote workstation or by the remote workstation interacting with the SSE. 

Simulation hardware models are selectable by the SSE operator. Model 
selections are made on panels presented on the MPAC. The operator can control 
the insertion of hardware model errors and model failures. The simulation 
defaults to idealized models in case the operator does not select an option on 
the panel. Customer supplied hardware models are supported. 

SSE software versions (developed or operational) are selected in much the same 
manner as the selection of hardware models. 

SSE simulation results are presented to the operator in the form of plots 
reports, etc. The operator developed test script controls the post processing 
of results. The results can be delivered to the operator on the MPAC 
display. The operator can select formats for hardcopy or display presentation. 

The SSE maintains parameter simulation files which contain software names and 
labels. Software parameters can be sampled at various locations during 
execution. The operator specified these locations and parameters in the test 
scripts. 

SSE aids are provided to isolate on-line errors (i.e., program exceptions). 
Errors are logged and traces are provided to aid the operator. Various 
monitoring devices are available to allow monitoring of the onboard Operating 
System (OS) and onboard Network Operating System (NOS) execution and 
performance during software development and testing. 

System tests are performed in the SSE by the operators. The flight computer 
mode, highest fidelity mode of hardware, will be used for system test. A high 
fidelity simulation occurs at this time and all the major hardware components 
are available. Some hardware interfaces are still simulated. The simulation 
fidelity level will be specified by the operators. 
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The operator training task at any facility involves those functions of the 
data system needed to train the onboard and ground personnel to operate: the 
Space Station, the constellation elements, the ground facilities, and 
payloads. There are three primary personnel groups: 

1 . Onboard operators 

2. Ground facility operators 

3. Customer/operators. 

Onboard and ground facility operators will require periodic training of 
off-nominal conditions that are not encountered in the day-to-day operation of 
the Space Station, and in operation of payloads that will not be directly 
controlled and monitored by the payload's owners. These conditions would 
typically be emergency procedures that require more rapid response than is 
available from textual reference to. fault recovery procedures, or infrequent 
procedures . 


4.4.2.4.13 Planning and Scheduling. These operator tasks are among the most 
important and difficult to achieve in order to produce effective coordination 
of requirements and resources. Without well understood objectives and timely 
plans to achieve them, an inordinate amount of operator time will be wasted in 
support of system operation and customer objectives. 

Planning and scheduling applies in some degree to all operator tasks. A 
starting point is to begin with customer requirements and basic core system 
requirements. A view of the overall process is illustrated in Figure 4-31. 

The basic core and customer requirement inputs and established SSP program 
objectives and priorities are utilized by the SSP community as a whole to 
develop operational plans. For clear objectives, a programmatic plan is 
established which becomes the skeleton for specific mission plans. From the 
mission plans, long-term plans are developed which are utilized by operators 
to develop near term plans which are then used to control the operations of 
the various SSPEs. The status of the SSPEs provide feedback in this process 
that can cause changes in the various multilevel plans to accommodate the real 
environment operations. The entire set of information or plans is called the 
Flight Data File. 
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Figure 4-31. Planning and Scheduling Provides Coordination of Requirements and Resources 

The above process generally describes planning and scheduling for onboard and 
ground operators performing station core tasks and operators supporting 
customer payloads. The view presented herein is that the planning and 
scheduling process for onboard and ground operator directly performing core 
and customer tasks and those operators supporting these operations will be 
merged together into a uniform plan. 

Generally, all plans are electronically available to any operator. Special 
security needs are accommodated. The process begins with premission (i.e., 
preoperations) activities that must accommodate basic SSP goals and 
requirements. Mission manifests are utilized to determine the desired habitat 
and customer needs and resources. The premission plan baselines ground and 
onboard personnel support levels and skills required. Ground resources are 
established to provide basic support from the (1) NSTS, (2) SSCC, (3) DHC, (4) 
RDC. Onboard system resource needs are similarly established: (1) avionics 

services, (2) subsystems, (3) OMV, OTV, and EVA, and (4) data management 
services and storage. Next, an integrated communications and network 
utilization baseline is established. Iteration of these early 
premission/preoperations requirements evolve into the accepted mission plan. 
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The next step is the development of a long-term plan. This is defined by 
ground operators and customers for on-orbit operators to follow. Plans are 
blocked out by operator and task for approximately a two week period. This 
integrated plan coordinates all known ground and flight systems status (core 
and payload). This plan is uplinked to the on-orbit operators. It becomes 
the skeleton of the near-term crew activity plan (CAP) developed by the 
on-orbit operators. 

The on-orbit operators use the skeleton long-term CAP, onboard data and 
status, and communications with ground operators and customers to create the 
near-term CAP. This covers a one-to-two day period. The on-orbit operator 
can best develop the detailed plan and schedule based on their station 
environment knowledge and crew skills and status. 

4.4.2.4.14 On-orbit Mission Support. The on-orbit operator task functions 
are: 

1. Coordinate operations with ground customer. 

2. Operate necessary customer payload/experiment equipment. 

3. Maintain/service customer equipment (reference 4. 4. 2. 4.1, Hardware 
Maintenance, for viewpoint). 

4. Perform EVAs as required. 

5. Execute training for specific customer related tasks. 

Both the Mission Specialists and Station Specialists share their scheduled 
work time supporting, as necessary, all the Space Station and COP payloads and 
experiments. They are, in general, not experts in all the payloads. The 
customers or principal investigators are, in general, on the ground. This 
does not preclude a customer or expert operator from becoming an on-orbit crew 
member for a long duration need. 
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The preceeding includes autonomous operation of a payload by the customer with 
only occasional support by on-orbit operators. 

The customer coordination needs may be very extensive. Voice and video are 
utilized between the customer and onboard operators. Common data base access 
for both is the prime means for recording/updating experiment operations 
procedures. These data are contained in the Flight Data File. Customers are 
expected to provide their equivalent of a Flight Data File to Space Station 
specifications. 

4.4.2.4.15 Customer Coordination. This ground operator task directly 
supports the customer by providing the following: 

1. Point of contact for customer to assist them in general SSP policy 
and procedures. 

2. Specifically includes: 

Front-end negotiation for customer experiment integration into 
planned profiles 

Training of customer and a Mission Specialist will address Space 
Station environment and procedures, and standard customer 
services — voice, video, data processing, and problem reporting. 
Handling and transportation of payload. 

Arrange/contract data links and processing to acquire data and 
move it to customer. 

Training of customer and Mission Specialist(s) to acquire data. 

3. Negotiation of NASA provided services beyond the standard services. 

These ground customer specialists share their time among several customers. 

The time spent is proportional to prenegotiated services. Telemetry service 
and data rates will be based on the amount of data captured, stored and 
delivered. 
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4.4.3 Space Station Data System Build-Up Scenario 


The current NASA plans call for an operational Space Station during the early 
1990's. One of the challenging aspects associated with this goal, is that of 
"Station build-up", defined as the set of activities that transform the fully 
developed Space Station elements into the deployed, operational, IOC system. 
This scenario is intended to provide some insight into the Space Station 
Program (SSP) build up activities while focusing on its Data System (SSDS) 
operations. The objective is not to develop a comprehensive description of 
the build-up procedure but to insure that Station requirements imposed on the 
SSDS by the Station configuration at each step of the build-up can be 
satisfied by the SSOS capabilities provided at the corresponding step. These 
requirements must also include those uniquely associated with build-up. 

There is a tendency to think of "build-up" only in terms of the space segment 
because of the associated unique accessibility/environmental issues; however, 
ground segment support is such an integral part of the over-all operation 
that, in the general case, the ground elements must also be addressed. 
Conceptually, the ground segment will be initially emplaced and activated in 
order to provide maximum support for the space segment preparations, and 
activation. The actual station hardware must itself be segmented into launch 
packages for NSTS transport to the defined low earth orbit and integrated in 
an orderly sequence into the defined IOC configuration. Specifically, then, 
the build-up activities will include: 

1) installation/activation of the program ground segments, 

2) space segment launch preparations and launch operations 

3) launch package on orbit deployment and assembly to existing structure 

4) activation and checkout of added Station equipment and capabilities 

5) full verification of SSDS operation and performance at final assembly 

6) full crew manning of Station 

7) installation/deployment and activation (as required) of 
experiments/payloads 
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Clearly, the build-up planning effort must generate a comprehensive task 
sequence with sufficient definition early in the acquisition phase to 
effectively interface with the design/development activities. 

A distributed networking approach Is anticipated for the Station SSOS since 

• the Station itself has physically distributed modules and sub-systems 

• processing loads may be too large to be efficiently supported by a 
centralized configuration 

• network technologies with adedquate data rates to support SSP 
applications are currently being defined/developed and will be 
available for IOC 

• this approach provides the modularity that supports 

a) commonality/standardization 

b) technology Insertion 
and, c) orderly growth 

Technology/design details of the SSQS have been minimized In an attempt to 
maintain generic concepts; however it has been necessary to generate a 
ground/space allocation of SSDS functions and to provide a distribution of 
sub-system equipment across the Station structure and modules to support those 
functions. The intent of these assumptions and allocations is only to provide 
a target final configuration to be achieved within the scenario, not to 
espouse any particular design features. 

With respect to the space segment Build-up, the distributed approach also 
supports the derived requirement to maintain a stable, self-powered, ground 
controllable configuration at each stage of the operation as subsequently 
discussed. 

An initial task of the scenario development was an assessment, provided in 
Table 4-8, of SSDS functional requirements at each stage of the build-up sequ- 
ence. This assessment led to a distribution of SSDS functions across the Sta- 
tion, i.e., launch packages as shown in Figure 4-32 and an Insight into the 
SSDS equipment requirements within each package. These requirements are 
integrated into Table 4-9 which summarizes the over-all scenario in terms of 
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Table 4-8. Build-Up Functional Allocation 
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Figure 4-32. Preliminary Space Station Functional Distribution 
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•Temporary Equipment/Functions 


1) the sequence of launch packages, 2) derived Station operational 
requirements (at each stage), 3) the SSDS functions to satisfy the Station 
requirements, and finally, 4) the equipment added to perform the SSDS 
functions. 

The basic approach to the space segment build-up scenario is the deployment of 
each launch package outfitted with its full IOC. A policy established for the 
scenario was the activation of these added capabilities as soon as possible in 
order to provide early exposure of problems and to maximize crew familiarity 
with the Station operating characteristics. When a module Is added to the 
Station, for example. Its equipment will be powered up in a predefined 
sequence, excercised through its Built-In-Test (BIT) diagnostics, configured 
with its appropriate software and brought on-line to allow NSTS and ground 
crews to perform Incremental system verification tests. Operational realities 
cannot be pre-defined however it is anticipated that much of the Station 
autonomy will be Initially over-ridden by ground control; responsibilities 
will migrate from ground to space as the Station develops and ground crew 
confidence increases. 
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Table 4-9. Scenario Summary (Page 1 of 2) 
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LAB2 THERMAL CONTROL SYSTEM 
LAB2 SAFE HAVEN 



Platform and free flyer deployment/activation are not separately discussed in 
this paper since build-up operations for these spacecraft is expected to 
closely resemble those of the Space Station build-up operations. There will 
be some interaction between these elements (during their build-up phase) and 
the Space Station, however, these interactions should not differ from the 
servicing and data support activities that are adequately documented 
elsewhere. The ground elements for these platforms and free-flyers are part 
of the SSOS ground segment and will not be separately addressed. 

Also, the man tended Station option has not been specifically addressed since 
it is concluded that this option would consist of build-up operations provided 
in following scenario, however an interim configuration would be maintained 
for the unmanned period, then upgraded to the manned configuration discussed 
in the following sections. 

The space segment build-up sequence provided in these discussions has been 
adapted from the reference 1 NASA Reference Configuration. The scenario 
presented here Is an expansion of that NASA effort. 

4. 4. 3.1 Data System Ground Segment 

The SSDS ground segment will consist of those elements (functions) required to 

• monitor and control the SS, COP, POP, and free-flyers 

• distribute uplinked data/commands and downlinked core and mission 
telemetry 

• capture, process, archive and distribute the core and mission telemetry 
data 

• develop software and hardware and provide system simulation and training 

• manage (scheduling, config. control, etc.) the above. 

These ground elements will include but not be limited to SS, COP, POP and free 
flyer Control Centers, POCC's, Engineering Data Center, Data Handling Center, 
Regional Data Centers, Development, Simulation & Training (DS&T) System, and 
Data Distribution Network and Network Control, plus the appropriate Interfaces 
to the NASA Technical, Management and Information System (TMIS). The TMIS is 
expected to support the ongoing configuration management, scheduling, and 
readiness status functions required during the build-up. 
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Clearly, the build-up phase represents a period of uncertainty since it may 
represent the first 'all systems' integration effort. The ground elements 
associated with 'core' operations must, therefore, be in place with sufficient 
operational maturity to support monitoring and control of the first space 
segment elements. These capabilities must include effective sub-system 
monitoring and commanding, plus the ability to simulate system 
phenomena/anomalies, diagnose the cause(s), and design and validate solutions 
prior to effecting appropriate changes on the flight system. The Oata 
Handling Center, and other Network and Oata Distribution elements must also be 
ready to support the Initial data format and rate requirements. 

In reviewing the operations of ground system emplacement and activation, no 
specific technical or operational Issues have been identified that necessitate 
particular strategies or sequencing except, as indicated earlier, the need to 
have an operational system of sufficient capability to support the deployment, 
assembly and activation of the space segment. The high IOC data rate 
capabilities associated with capture, distribution, archiving etc. need not 
actually be operational until late in the Station build up sequence; however, 
any options excercised in this area must not Impact the over-all build-up 
schedule. The ground segment elements will Incorporate the 
standardization/commonality policies of the over-all program (SSP) such that 
individually verified equipment can be 'installed and activated' within each 
respective facility with minimal problems. The degree of pre-launch 
ground/space segment Integration will depend on the particular strategies 
selected, however the OS&T System, utilized heavily during 0DT&E of the ground 
and space elements, will continue to support the build-up and activation 
operations in any case. TDRS/dlstributlon links will be simulated at least 
initially and full end-to-end data checks may be deferred until the Space 
Segment is in place. 

The ground SSOS/TMIS combination will support the planning, scheduling, 
configuration management, and mission readiness, including pre-launch 
integration and checkout. The NASA/Contractor team will update the associated 
status data bases such that comprehensive, real-time visibility of build-up 
operations will be available via this 'paperless' system to perform effective 
program planning/scheduling. 
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4. 4. 3. 2 Data System Space Segment 


One of the goals of the on orbit space segment build-up task is to maintain a 
stable, self-powered and ground controllable configuration at each step of the 
operation. This goal, coupled with the constraints of NSTS payload limits, 
has led to the development of the plan presented in the NASA Reference [1] in 
which a specific sequence of structural and module packages are boosted into 
near earth orbit for incremental assembly into the IOC configuration. The 
plan requirements drive the Station configuration and design in order to 
develop packages compatible with the NSTS cargo envelope, weight, c.g., etc., 
and allow subsequent deployment and assembly within the projected on-orbit 
resources. 

Preliminary NASA planning accomplishes the build-up with 7 such packages, 
shown in Figure 4-33; a schedule of 6 - 12 months is anticipated for the 
effort, driven primarily by the launch preparations (NSTS refurbishment, launch 
package integration, and pre-launch checkout) and other impacting flight 
commitments. As indicated earlier, it is the intent of this scenario to 
Insure that this build-up sequence can provide, at the conclusion of each 
mission, an appropriate complement of SSOS hardware and software to meet the 
projected interim requirements of the Station. 

Ground operations between the initial build-up missions will focus on 
monitoring, controlling, and correcting the developing station, becoming 
thoroughly familiar with the station operations and operating characteristics 
at each stage of development. It Is possible that perturbations to this 
scenario may result from equipment failures. Incompatibilities or deficiencies 
detected during the build-up however, in the work case the resultant 
activities would merely be re-iterations (launch package removal and 
replacement) of the activities and operations presented. Such perturbations 
are therefore not specifically addressed. 

4. 4. 3. 3 Build-Uo Preparations 

% 

In the anticipated sequence of build-up preparation, the flight segments of 
the SSDS, will first be integrated and verified within their parent elements 
of the Station. These elements will then be assembled for Station system 
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integration and verification prior to launch according to the selected 
Integration strategy. Finally, system elements will be assembled into 
assigned launch packages for Orbiter integration, pre-launch checkout, and 
launch. Orbiter integration will require special preparation and attachment 
of structural members however, the SSDS equipment located within module or 
structural housings should not be impacted. 

During pre-launch operations some SSDS checkout is anticipated with the 
packages in the Orbiter bay. Several options are available to accommodate 
this checkout, depending on the required depth. This scenario, however, has 
shown a need for an interface between the Orbiter and the SSDS to allow the 
orbiter crew to perform on orbit monitor and control functions on the Station 
sub-systems. OMS common equipment, (MPAC, Bill, and processors), may therefore 
be Installed within the Orbiter to support this function; the network 
interface(s) will most likely be provided through the docking port. This 
Interface could be harnessed to the launch package within the cargo bay to 
perform at least confidence level diagnostics. If required, more 
comprehensive system level checkout could be performed prior to Orbiter 
integration using a combination of specific GSE at the launch site plus remote 
system simulation support provided by the Software Support Facility. It is 
anticipated, however, that some checkout of the launch package will be 
required prior to its removal from the Orbiter bay to establish that no 
significant damage has occurred. Power will be provided from an auxiliary on 
the Orbiter for this operation and the SSDS interface will be utilized 
(through the special harnessing above) to perform this checkout. 

For the actual launch and orbital boost. It is assumed that there is no 
continuous power requirement for any of the station equipment, sensors, or 
experiments, and each package will be 'cold started' on orbit. 

4. 4. 3. 4 Build-Up Operations 

The following discussions provide general descriptions and features of each 
launch package, an overview of each mission with the identified Issues, and a 
discussion of the SSOS operations and Issues. 
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For all orbital construction tasks, the Orbiter will be rigidly attached to 
the developing Station in order to reduce dynamics complexities and minimize 
collision risk. The Shuttle Remote Manipulator System (SRMS) grappling 
capability will be used to maneuver the Orbiter and/or Station into coupling 
position with temporary or permanent docking ports utilizing engagement 
mechanisms and some aids for range, range rate and attitude will be utilized. 
For the remainder of the discussions, these attachment operations will merely 
be referred to as berthing. Impact dynamics during berthing, SRHS/MRMS 
loading/unloading operations, and resultant attitude control requirements are 
acknowledged to be significant Issues but will be appropriately left to others 
for comprehensive analysis and discussion. 

Communications will play a major role in developing the Station configuration 
and a number of associated Issues must be resolved. Of particular concern are 
the Station/Orbiter communication Interfaces. It is not intended to provide 
solutions or even options to such issues within this document. Instead, 
communications functions will only be generically addressed with the 
assumption that appropriate conversions and/or compatible transponders can be 
utilized. 

4. 4. 3. 4.1 Flight #1 

4. 4.3. 4. 1.1 Package Definition 

The initial build-up mission will deply the Station Transverse Boom shown as a 
folded launch package in Figure 4-34 and unfolded In Figure 4-33. The 
preliminary configuration provided in reference [1], locates hardware for the 
Electrical Power System (EPS), Thermal Control (TCS), and Guidance, Navigation 
and Control (GN&C) sub-systems across the Boom a shown in the figure. The 9 
foot cube at the center of the structure, identified as the Attitude Control 
Assembly (ACA) compartment will house the Inertial Sensor Assemblies (ISA)'s, 
CMG's of the GN&C sub-system, and regulators/distribution equipment of the 
electrical power system (EPS); solar arrays and regenerative fuel cells will 
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Figure 4-34. Transverse Boom Launch Package 


be located further out on the boom structure as may be the Magnetic Torquers 
of the GN&C. 

Addition of communications and some SSOS capabilities, will allow the Boom to 
be deployed as the initial stable element around which the Space Station can 
be assembled. 

The SSDS capability will require a set (or sets) of processors, memories, mass 
storage devices, etc. but Is expected to be temporary in that its functions 
will be transferred when the permanent equipment Is integrated into the 
Station. However the equipment may remain in place as a spares resource and 
also for contingency purposes. Other options Include use of a 'throw away' 
unit or permanently locating some function in the ACA. Networks/busses will 
be provided to permanently Interface this equipment to the sub-systems NIU's 
and to the OMS of the final IOC configuration. 
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The communications equipment must Include both a NSTS and TORS S-Band 
capability. One option for the TORS link would be to provide the full IOC 
capability within the boom structure then relocate the antennas, amplifiers, 
and recievers etc. to the upper boom when Installed. The alternative, 
proposed in reference [1], utilizes low gain S-Band equipment for all 
communications on the Initial configurations. This latter approach is 
basically compatible with the requirements and has therefore been adopted. 

GPS receivers will be included In the preliminary configuration to provide 
position, velocity and time reference to the GN&C sub-system. 

Thermal control equipment, radiator panels, etc., provided on the Boom for 
Power Sub-system equipment cooling will also accommodate the added QMS and 
Communications equipment. 

The initial SSDS will have an autonomous capacity to perform the Station data 
and command management functions plus, subsystem supervision and redundancy 
management. Consistent with IOC design requirements, the ground crew will 
have the ability to over-ride all operations. 

4. 4. 3. 4. 1.2 Mission Overview 

The first mission will remove the Boom structure from the Orbiter cargo bay 
using the Orbiter SRMS, and fully 'construct'/deploy the boom with its first 
set of solar arrays. Typical of most build-up operations, this activity will 
be EVA Intensive. Communication between EVA and NSTS crew will be relayed to 
ground as usual . 

For the start-up/checkout operation, the Orbiter will be attached to the Boom 
at its temporary docking port utilizing the Orbiter attitude control system to 
sun orient the boom solar panels for the activation of the Electrical Power 
Generation System. An alternate possibility, however, is to allow the Fuel 
Cell system to provide the start up power and allow the station to 
autonomously orient the solar arrays when the DMS and GN&C subsystems are 
operational. The Power Management and Distribution equipment will be 
activated and configured followed In sequence by the DMS, Comm, and GN&C 
subsystems. 
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The last major operation will be to checkout the Mobile Remote Manipulator 
System (MRMS). It will be positioned at its designated servicing station 
which will supply power for manipulator operations and recharge its batteries 
for mobile operations. The MRMS will be excercised both from Its local 
control panel and via its S-Band RF link. 

4. 4. 3. 4. 1.3 SSDS Operations 

The SSDS equipment will be powered and software configured via an automatic 
ROM boot st rap /memory load technique typical of all the equipment, power up 
BIT/diagnostics will also be performed. The SSOS will perform Its 'manage 
delivered data' function by accumulating the sub-system data, formating the 
data packets with appropriate header/trailer data and issuing the resulting 
data stream to the Comm system. This low rate data will not require any 

substantial OMS or Comm buffering and will be compatible with the S-Band links 

provided. The Comm system will begin transmitting the Station sub-system 
'operation and health 1 (house keeping) data stream to the ground via the 
Orbiter for evaluation. The SSDS ground system will perform functions of data 
capture, data handling, and processing to support real time displays and trend 
analyses for ground crew evaluation. The raw data will also be archived 
within the Engineering Data Center for available access and additional 
processing by ground personnel. As previously Indicated, the Orbiter will 
have access to the OMS via Its onboard workstation (MPAC) interconnected 
through the docking port. This access will allow any special sub-system 
diagnostics or verification tests to be performed or any operating mode to be 
established. The GN&C equipment (ISA's, CMG's, star-trackers, processors and 

BIU, etc.) will be powered up and its associated processors (dedicated or 

assigned) initialized and brought on line under DMS control. Some time 
(perhaps hours) will be required for the GN&C equipment, i.e. CMG's to reach 
operational status. 

During this period, the GN&C will be placed in an 'attitude hold' mode to 
disable all control command outputs, however the sub-system will begin its 
initial attitude determination/update utilizing the sub-system star trackers, 
then begin to navigate based on incoming GPS data. Ephemerls data will be 
provided in secondary storage for DMS/GN&C to propagate orbit parameters and 
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begin control and pointing command generation. GN&C command and data products 
will be Interrogated/monitored by NSTS (via Orbiter MPAC) and ground crews 
with updates/adjustments provided as required. When operation is judged 
acceptable, command outputs will be selectively enabled and the GN&C will slew 
and maintain the solar arrays to appropriate pointing angles. 

At some point in the mission the Station/TDRSS S-Band link capability will be 
exercised with the ground crew monitoring the Station and exercising the 
repertoire of commands required to control the DMS and other subsystems. The 
OHS will receive the uplinked commands and data provided by the Comm system, 
perform validation and authentication checks, then issue the commands and data 
to the appropriate subsystem. 

The final SSOS capabilities will be that of subsystem monitoring and 
configuration management. The 'operation and health' data of each subsystem 
will be monitored and appropriate action taken depending on the fault 
tolerance techniques employed. Typically, each subsystem processor will 
reconfigure Its own sensors and effectors as required, however, the initial 
DMS may have the capability to reconfigure and initialize the sub-system 
processors. 

When NSTS and ground crews are satisfied with the station operation, the 
attitude control operation will be verified by disabling the Orbiter control 

system and allowing some low level of control by the Station. With normal 
indications, the Orbiter will disengage to a safe distance and ground crews 
will fully enable the attitude control . Autonomous momentum management will 
also be provided by the SSDS utilizing the magnetic torquers however this 
function may be initially assumed by ground crews. 
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4. 4. 3. 4. 2 Flight #2 


4. 4. 3. 4. 2.1 Package Description 

The second flight package will consist of the Keel structure plus lower 
assembly support bays shown In Figure 4-33. IOC equipment on the structure 
will include Reaction Control System (RCS) and Thermal Control Sub-system 
(TCS) hardware. 

4. 4. 3. 4. 2. 2 Mission Overview 

For this mission the Orbiter will berth at the port on the Transverse Boom; 
the ground crew will command the GN&C into the 'attitude hold' mode as the 
Orbiter approaches. When docked, the Orbiter will establish an optimum, 
stable attitude to support the assembly operations. 

The initial build-up operation will checkout and position the MRMS which will 
be used in conjunction with the SRMS to remove the upper keel structure from 
the Orbiter bay. When the main body of the keel is assembled to the boom, the 
MRMS will be 'walked' down the keel to support construction of the lower keel 
assemblies. Redundant service lines (DMS networks, TCS & RCS ducts and power 
distribution cables) will be connected/attached to their respective 
sub-systems. These service lines may be pre-integrated or may be carried 
separately; in either case they will require routing and securing within the 
previously packaged structure. 

The RCS equipment (thruster nozzles, drivers, instrumentation, etc.) mounted 
on the keel will be used for orbit adjustments, collision avoidance and for 
back-up momentum management. The TCS equipment (fluid pressure vessels, flow 
control devices system processor(s) , instrumentation, etc.) will provide and 
control heat exchange with the Station main thermal radiator panels to 
maintain appropriate temperature sinks for the Station equipment. 
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Both systems will be activated, and checked out. Reserve propellant tanks 
attached to the lower keel structure will support the RCS checkout. 
Instrumentation packages within the Keel structure will monitor 
vibration/flexure modes and structural misalignment. At the conclusion of the 
mission the Orbiter will disengage. Ground personnel will establish a 
favorable gravity gradient station orientation. 

4. 4. 3. 4. 2. 3 SSDS Operations 


No additional SSDS functions are provided by this mission however the existing 
SSDS capabilities will support the routing of commands from the GN&C subsystem . 
to test fire the RCS jets under ground crew control. The structural 
instrumentation will be treated as a set of Isolated sensors. The resulting 
data will be monitored by the appropriate 'caution & warning' function of the 
SSDS and will be Included within the downlinked engineering data. 

4. 4. 3. 4. 3 Flight #3 

4. 4. 3. 4. 3.1 Package Definition 

The third mission will include the first habitation module, HM1 , with the two 
Station Airlocks All & AL2 shown in Figure 4-33. AL2 will be subsequently 
removed and permanently attached to HM2. As indicated in Figure 4-33, HM1 
contains DMS, Comm, ECLSS, TCS equipment plus crew facilities and "Safe Haven" 
capability. 

4. 4. 3. 4. 3. 2 Mission Overview 

The Orbiter will dock/berth to the temporary docking port at the starboard 
keel extension. This port will Include the DMS/C&T interface. For this and 
subsequent missions, the Station attitude control system will remain 
operational and the Orbiter ACS will be inhibited prior to berthing contact 
and securing. The MRMS will be relocated to support SRMS removal of the 
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module and its attachment to the lower keel structure. Module utility lines 
(electrical power, SSDS/CStT links, and TCS/ECLSS ducting) will then be 
attached. Finally, All and AL2 will be attached to the module. Following 
module attachment, the Orbiter will berth at the HM1 docking port. 

The module equipment will be activated and checked out as much as possible 
prior to Orbiter departure. However, two Issues must be addressed in order to 
speculate on the immediate utility of the HM1 capabilities. First, it is not 
clear that the stand-alone module can initiate and maintain its 'shirt sleeve' 
environment for effective use as a work/rest station. Secondly, it is not 
clear whether the electrical/electronic equipment can be activated and checked 
out within the unpressurized module due to thermal considerations. 

This scenario will assume that the module ECLSS will not have the stand-alone 
capability, therefore, the crew will remain suited for all flight #3 and #4 
module activities. This will not only limit the utility of the module but 
will delay the detailed module checkout of the man/machine Interfaces until 
flight #5. On the second issue, it will be assumed that the module electrical 
equipment can be operated in the unpressurized environment with the available 
Thermal Control equipment and cold plates in each module. 

Suited crewmembers will enter the module via the docking port to configure and 
perform a limited module checkout. Following module checkout, the crew will 
establish a predefined module configuration, and depart with the Orbiter. 

4. 4. 3. 4. 3. 3 SSOS Operations 

The HM1 checkout effort will complete the normal power up and self test 
operations then proceed with a communications verification, including 
voice/video to the Orbiter and communication via TORS to the ground. 'Safe 
haven' direct to ground communications will be excerclsed at appropriate orbit 
positions. The HM-1 SSDS equipment will be initialized with Its appropriate 
memory load and brought "on-line". Appropriate operational diagnostics will 
be performed with both local operation utilizing the MPAC and by the ground 
crew. 


143 



The SSOS equipment in this module will provide crew support functions, i.e 
medical, health maintenance, EVA support together with some general data 
storage and buffer capability. The HM-1 communications equipment signal 
processors will support the K and S-Band communication with TORS. 

4. 4. 3. 4. 4 Flight #4 

4. 4. 3. 4. 4.1 Package Definition 

The fourth NSTS package, shown in Figure 4-33, will consist of the second 
Habitation Module, HM2, plus the upper keel structure with its high 
performance (IOC) TORSS communication equipment. 

4. 4. 3. 4. 4. 2 Mission Overview 

The mission will begin with the Orblter berthing at HM1 . The MRMS will remove 
the HM2 module from the Orblter bay in conjunction with the SRMS and position 
It for attachment to the keel structure. These attachment operations differ 
In that HM2 will also attach to HM1 to form one half of the module "race 
track". Airlock AL2 will be relocated from HM1 to HM2 and the HM2 service 
links will be connected. The upper keel and boom structure will be 
transported via the MRMS under EVA control and assembled to the keel. The 9 
foot TORS antennas, power amplifiers, low noise amplifiers (LNA)'s and 
receivers will be located onto the upper keel structure to support the IOC 
ground link capability. 

Suited crewmembers will then enter HM2 and perform a checkout sequence similar 
to that employed on HM1 . 
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4. 4. 3. 4. 4. 3 SSDS Operations 


The OHS equipment within HM2 will include fixed and portable work stations 
(MPAC's) plus the processors, BIU's and mass storage to provide the functions 
of sub-system monitor and control, scheduling, operations sequencing, command 
management, traffic control, Facility Management, and Caution & Warning. Once 
the equipment is brought on line with an appropriate software load, the 
limited functions of the ACA SSOS equipment will be assumed by the HM1 and HH2 
equipment and the ACA equipment will be taken off line. Appropriate 
Command/control diagnostic checks will be performed from the ground. 

The added SSOS functions of scheduling, operations sequencing, along with 
enhanced Caution & Warning, and Facility Management functions, when 
operationally mature will reduce the ground crew requirements during and 
between Orbiter missions. The remaining functions within the module will be 
checked within the Inherent limitations of the suited crewmen; however, the 
GN&C, Comm and DMS will be configured, through ground and Orbiter crew 
commands, to activate the high gain direct TORS link. 

4.4. 3.4. 5 Flight #5 

4. 4. 3. 4. 5.1 Package Definition 

The fifth package as shown in Figure 4-33 will consist of the Logistics Module 
(LM), along with port and starboard extensions for the Transverse Boom to 
support the second set of solar arrays. 

4. 4. 3. 4. 5. 2 Mission Overview 


As usual, the Orbiter will dock at the HM1 docking port. The MRMS will remove 
the Logistics Module from the cargo bay and position the module for positive 
mate to HM2 and attachment to the keel structure. The normal connection of 
utilities, power, and thermal control will occur. 

A major activity of this mission will be the activation of the LM, HM1 and HM2 
ECLSS system to provide module habitability and a second base for EVA support. 
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The Transverse boom extensions will be deployed utilizing the MRMS under EVA 
control followed by attachment of the set of solar arrays. 

4. 4. 3. 4. 5. 3 SSDS Functions 

Suited crewmen will enter HM1 through the docking port and cross into the 
Logistics Module to configure its ECLSS equipment, pressure sources and 
regulators and sinks. HM-2 first and then HM1 will be configured to accept 
the LM supply pressures of gas, water etc. and their ECLS systems will be set 
to normal design conditions. 

Once monitoring on ground and within the module indicate an acceptable crew 
environment, the crewmen will de-suit and begin the comprehensive checkout of 
each habitation module. This checkout will verify the full workstation/OMS 
capabilities and voice/video comm capabilities between modules and Orbiter and 
ground. The EVA servicing and support functions will also be checked, in 
addition to other crew support functions not previously excercised. All 
discrepancies and anomalies will be worked with ground crew utilizing full 
audio/visual (TV, text, and graphics) communication capabilities. Effective 
troubleshooting can be performed to isolate faulty equipment and return it 
with the Orbiter. 

At this point, the program has the option of leaving a 2-3 man crew at the 
Station to support the on-orbit Integration operations. The decision would be 
based on factors of overall utility and the demonstrated station safety and 
reliability. 

4. 4. 3. 4. 6 Flight #6 

4. 4. 3. 4. 6.1 Flight Package 

The Flight No. 6 will consist of laboratory module, LAB 1. This module, as 
shown in Figure 4-33, contains a major portion of the C&T control and process- 
ing equipment associated with traffic control, the QMS payload collection and 
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distribution equipment, and the standard communication (voice/video) access, 
ECLSS, and "Safe-Haven" equipment. 

4. 4. 3. 4. 6. 2 Mission Overview 

For this mission, the Orbiter will dock at HM1 and the MRMS will be translated 
down the keel for access to the Orbiter and the LAB 1 attach point. LAB 1 
will be removed and positioned using the combination of SRMS, MRMS and EVA 
support. Following mechanical securing of the module and attachment of its 
utility lines, the crew will checkout and configure the module to establish a 
habitable environment for subsequent checkout. 

This mission provides a second opportunity to leave a 2-3 man crew on-orbit to 
support continuing station checkout operations . Experiments housed within 
the Lab 1 module could also be activated at the conclusion of the mission, 
depending on their support requirements. 

Any defective equipment identified during this or earlier checkout could be 
removed by the crew for onboard repair or return to earth, since the orbiter 
will have available cargo space to deliver repaired/replacement equipment on 
both the 6th and 7th flights. 

The LAB 1 module will be configured for either a 'manned' or 'man-tended' 
operation depending on whether a partial crew remains within the Station. 

It should be noted that the SSDS functional distribution provided in Figure 
4-32 dictates a deviation from the Reference Configuration in that LAB 1, with 
its customer data management, mission support, and ancillary data management 
functions, has been deployed first to provide a more operationally continuous 
build-up sequence. There has been no consideration for any structural 
difficulties that this deviation might cause. 


147 



4. 4. 3. 4. 6. 3 SSDS Operations 


Once the LAB 1 module has been powered and is habitable, its communication 
equipment will be checked out followed by activation of the DMS and Comm & 
Tracking equipment. It is also anticipated that some payloads/experiments 
within this module will be activated to satisfy associated 'user' agencies and 
also to support some limited system checkout. The added SSDS functions within 
this module are those of 'customer data management', customer operations 
support' and 'ancillary data management'. The Comm & Tracking equipment 
includes signal and data processors for constellation tracking functions and 
to support video/data formatting associated with the TDRSS forward and return 
links. 

System level checks will be initiated from the HH1 workstation in conjunction 
with ground crews to fully exercise the payload oriented capabilities. These 
exercises will Include command and monitor sequences by ground and on-board 
crews to: 1) verify command management functions, 2) verify payload sequencing 
operations, 3) verify the distribution of ancillary data for payload access, 
and 4) verify the end-to-end, multi -experiment (and core) data flow including 
ground archiving and distribution to user. 

4. 4. 3. 4. 7 Flight #7 

4. 4. 3. 4. 7.1 Package Description 

The last station build-up package will consist of the LAB 2 module plus any 
replacement/returned equipment. 

4. 4. 3. 4. 7. 2 Mission Overview 

This mission will berth to HM1 and utilize the MRMS and SRMS with EVA support 
to emplace the LAB 2 module. 

This module, as shown in Figure 4-32, will house the normal ECLSS, TCS, 
communication access. Power, and "safe haven" equipment plus DMS equipment in 
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the form of work stations, data processors, and mass storage equipment, to 
support functions of customer data management and customer operations support. 
The module activation/checkout sequence will follow the previous flow and 
finish with system integration of its functions via HM1 and HM2 operations. 

4. 4. 3. 4. 7. 3 SSDS Operations 

When the module has been powered up, and is habitable, the normal checkout 
will proceed with verification of communications (voice/video) and its 
workstation. Then, as with the LAB 1 checkout, some payload/experiments 
within the module will be activated and end to end checkout performed. This 
module, as indicated in Figure 4-33, will house the large mass storage 
equipment utilized during zone of exclusion (ZOE) period and for general (load 
relief) data buffering as required. 

4.4. 3. 5 Initial Operational Capability 

At the conclusion of the 7 mission sequence, the SSDS will be fully in place, 
performing or ready to perform all defined functions. Additional flights will 
be required, however, to transport the OMV, additional payloads/experiments/ 
free flyers, and personnel required to supplement the Station crew and thus 
achieve the IOC station configuration illustrated in Figure 4-35. Also, there 
will be some transitional, start-up period to bring the Station up to a 
routine working status. There will be a heavy reliance on the robustness, 
i.e. flexibility and tolerance of the SSDS during this period since its 
background tasks must be continued while supporting ground/station crew real 
time tasks and adapting to the growing payload/experiment mission support 
requirements. Equipment problems will inevitably occur during this period as 
will human errors; the systems must discriminate faulty conditions and command 
sequence errors while continually prompting the crews for appropriate 
actions. This will not only test the dynamic and static fault tolerance 
features of the subsystems but will also be a challenge to the short term 
scheduling and operations sequencing capability of the SSOS. 
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The activities required to emplace and activate payloads and experiments 
should not present any particular difficulties after the 7th mission. 

Internal (pressurized) payloads/experiments will be carried through from the 
Orbiter, through the habitation modules to the Laboratory Modules. Size 
limitations must be imposed to insure appropriate clearance through this 
path. In the Laboratory modules, the payloads/experiments will be placed on 
standardized racks with 'standardized' interfaces for power, SSOS functions, 
and thermal control as required. The checkout will be initiated with a power 
up, built in testing (BIT) operations. Scheduling of this testing and the 
monitoring of its results will be performed locally on the Laboratory work 
station. Voice and video communication will be available directly to the 
associated user agency for use as required. Once this checkout is complete, 
then the SSOS will be configurated to schedule the Payload/Experiments 
operations with respect to Space Station resources, and data management. 

Externally mounted payloads, particularly the larger volume variety will be 
transported from the Orbiter bay, most likely under EVA control, to their 
structural mount. The payloads will be mounted at prepared locations with the 
standard interfaces to electrical power, thermal control, and the SSOS. 
Rotating mounts will be available as required. Portable MPACs will be 
utilized by the EVA personnel to support the initial checkout and appropriate 
configuration of the payload. Voice communication will be transmitted to the 
associated user along with video provided by remote cameras. Provisions must 
be made to support this local operation of the MPAC and video camera. Once 
the payload has been judged operational, its schedule will be established via 
command through the MPAC to the SSOS scheduling function. 

The scenario proposed for this initial build up provides a key advantage in 
that on-orbit integration and verification is performed incrementally, 
allowing early and continuous evaluation of each subsystem as deployed. Thus 
adjustments and corrections can be applied in a more timely manner. This 
approach is, of course, heavily dependent on, and strengthens the arguments 
for a distributed subsystem architecture. The alternative, centralized 
approach would necessitate deferment of any significant system verification 
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until the major elements of the Station had been assembled and presents a 
somewhat higher risk to the over-all program. 

4.4.4 Space Station Growth Scenario 

A growth phase for the Space Station is predicated on currently projected 
mission manifests and foreign (international) Station involvement plus 
addition of the Orbital Transfer Vehicle (OTV) with its mission operation and 
servicing requirements. It is also anticipated, however, that the reality of 
an operational Space Station will stimulate unscheduled demands for 
payload/experiment support in both high and low earth orbits. This support 
will translate into additional laboratory modules and payload truss mounts, 
additional habitation modules, additional structure, and additional capacities 
in all sub-systems as diagrammed in Figure 4-36. While some elements and 
options of growth can be formulated to a reasonable degree, the actual growth 
path cannot be defined because of the mission demand uncertainties and to a 
lesser extent, the unpredictability of technological advances. 

With respect to the SSOS, the key growth drivers will be: 1) Increased volumes 
of data to be handled at higher data rates, 2) increased free flyer (and 
tethered) traffic, and 3) increased space/space and space/ground 
communications requirements. More processing power, more mass memory, and 
higher data transfer capacities will clearly be required, coupled with 
improved space/ground communication paths, i.e. TDAS and direct broadcast. 
Growth activities are expected to occur in discrete and potentially 
independent steps. The distributed SSDS topology anticipated for IOC appears, 
therefore, to provide an optimum baseline for the growth scenario, but must 
Incorporate flexibilities for growth that have been planned from the inception 
of the program. 'Scarring' (built-in growth accomodation), will be provided 
wherever practical within the space elements, to absorb or anchor the 
additional capacitities and resources. 

The growth activities provide the opportunity not only to Increase mission 
support capabilities, but also to reduce operational costs through technology 
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Figure 4-36. Growth Issues 









upgrades, and to reduce ground support requirements through implementation of 
more Station automation and autonomy. Technology upgrading (or insertion) 
will be supported through continued use of standardized hardware such that 
higher performance, higher reliability products of reduced size, weight, power 
and cost can be 'dropped in' with minimal impact. Greater automation and 
autonomy will require more use of artificial intelligence and robotics, both 
of which are expected to proliferate in the growth time frame. 

The specific drivers and Impacts of growth are discussed in the following 
paragraphs . 

4. 4. 4.1 Ground Segment 

The growth of the ground segment and its drivers cannot be specifically 
tracked since significant changes In the configuration of the space/ground 
link are expected within the growth period. Thus, although the projected 
mission set may generate higher aggregate data rates and volumes, addition of 
Improved beam switched communication satellites and/or direct broadcast will 
relieve much of the ground data handling/distrlbutlon demands through use of 
more distributed approaches. 

There will be a continuing effort to reduce operational costs of the SSDS 
ground system by reducing ground crew requirements through the use of enhanced 
automation and 'expert systems', and through the use of more reliable, more 
fault tolerant hardware to reduce down time and maintenance requirements. 

Software upgrades will be an Implicit part of growth to correct Identified 
deficiencies and enhance user (customer and ground crew) utility. This is 
likely to be a significant program cost driver beyond initial development 
costs. Provisions for cost effectively accommodating software upgrades must 
be a major consideration in early definition and planning. 

No significant technical drivers can be identified in these 'growth' 
modifications since the ground elements are not Impacted by volume, weight, 
power constraints or accessibility limitations. Addition of ground terminals 
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within regional data enters or remote customer facilities to accommodate 
direct broadcase will be accomplished with no particular difficulty. In 
summary then, the SSP ground segment 'growth' can be characterized as: 

1) enhancements to the space/ground communication and data distribution, 
supported at least in part by direct broadcast from Station or through 
advanced communication satellites 

2) enhancements in data handling, resource planning/scheduling, etc. 
utilizing 'expert systems'. 

and 3) software upgrades to correct identified deficiencies and improve 
user utility of the SSOS with a relatively unconfined environment. 

The issue to be resolved Is that of location and capability of the Data 
Handling Center (OHC). Current planning, co-locates the DHC at the White 
Sands Ground Terminal. When direct broadcast to the Regional Data Centers 
(e.g., TDAS) is Implemented the DHC functions that are duplicated with the 
Regional Data Centers will disappear. The majority of the remaining functions 
will migrate to orbit. The IOC location of the DHC should consider the smooth 
transition to the growth phase. 

4. 4. 4. 2 Space Segment 

The Space segment, in contrast, will be continually constrained by volume, 
power, weight, and accessibility. In addition, sub-system capabilities cannot 
be significantly impaired during growth rework. 

As indicated in the Background, section, the demand for additional 
payload/experiment support translates to additional structure, additional 
laboratory and habitability modules, and additional sub-system capabilities. 
The laboratory modules will house the added payloads/experiments along with 
additional Comm G Tracking and DMS hardware/software for their support. The 
habitability modules will house additional DMS equipment Including normal 
MPAC's, and will support additional crew personnel, including mission 
specialists as required. The additional structure will be required for the 
attachment of these modules and any for additional external payload/experiment 
support. 
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Sub-system expansion must occur across the board to provide the increased 
capacities in the areas of power generation, thermal dissipation, attitude 
control etc. The primary Impact on the SSDS, however, is from the growth 
requirements of data handling, data base management, and communications 
although the distributed topologies postulated in the Build-Up scenario should 
adequately support expansions of the data/data base management capacities. 
Growth of the SSDS functions will be facilitated by spare capabilities built 
in to the IOC configuration. Spare network nodes, for example, and even spare 
networking can be provided in the IOC configuration along with the required 
additional sub-system associated cables and ducts. Local area networks 
(LAN's) within each added module can therefore be readily linked to existing 
backbone networks or to new backbones which are bridged to those existing. 

The data/data base management equipment within those modules will provide the 
horizontal growth required. 

Clearly, some vertical growth can be Implemented through technology insertion, 
the replacement of existing ORU's or perhaps single card's to provide more 
faster, lower power, or (for the Polar Platform(s)) more radiation tolerant 
hardware. 

Continued utilization of standards will be mandatory in the growth phase to 
insure compatibility of physical and logical interfaces such that replacement 
hardware and software will essentially be a 'drop-in' operation, transparent 
to the system operation. 

Foreign Involvement is anticipated in the Space Station and may take the form 
of additional modules with potentially differing LAN topologies. Interfacing 
these modules to the SSDS can be effected through Imposed standards or through 
the use of internetwork gateways. 

Some growth will have more of an impact, particularly If specialized solutions 
are implemented for functions previously performed by general purpose 
hardware. A primary example of this Is the area of artificial Intelligence. 

A. I. machines and software will be further exploited during growth phases of 
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the SSP. Functions such as scheduling, operations sequencing, configuration 
and resource management, crew support i.e. physiological, biological, training 
are all strong candidates for A. I. expert system solutions. An implementation 
option, in such cases would be to house these new solutions in the added 
habitation modules. The function would then merely be with minimal disruption 
to function operation. 

The most significant driver to SSOS growth will be the management of the data 
that is collected from the additional experiments/payloads and free-flyers and 
delivered to the communication port(s) for transfer to the ground. This 
volume of data may require new solutions perhaps beyond the capabilities of 
the TORSS link(s), particularly in a multiple COP and POP scenario. Improved 
and multiple communications ports may be required to implement direct 
transmission to ground or use of multiple satellites with advanced 
technologies. 

The space segment growth scenario therefore consists of the following tasks. 

• replacement of ORU's and/or component cards to provide an expansion of 
capabilities. 

• expansion of sub-systems to provide more additional resources and 
support capabilities. 

• addition of structural elements and associated monitoring 
Instrumentation. 

• addition of the OTV to support high energy orbit transfer and 
servicing of payload. 

• addition of lab and habitation modules 

• addition of back-bone networks/bridges/gateways for the additional 
modules/nodes 

t addition of data management/communication equipment to transfer the 
Increased volumes and rates of data to the ground/users. 

Verification of these additional/modified resources will be performed in the 
same fashion as described in the original build-up, i.e. no specific 
additional growth implementation Issues are identified. 
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4.4.5 Operational Design Drivers 


One of the purposes of the operational concept definition was to identify key 
SSIS and SSOS design drivers that result from the operational concept. A key 
design driver is an operational, functional, or performance requirement that 
is expected to have significant impact on the performance, complexity, risk, 
or cost of the system. The following key operational design drivers have been 
identified: 

a. The need for system transparency as viewed by the customer will 
Impact system complexity by causing special provisions to be 
implemented to minimize data transport delays and to minimize system 
interactions that might constrain or Interfere with customer 
Independence. Certain delays are inevitable because of communication 
path propagation times and link outages. Additional delays, such as 
those caused by processing, reformatting, conflicts, or capacity 
limitations, need to be minimized in the design In order to provide 
good functional transparency. 

b. The quantity of data archiving requested by customers and the need to 
provide wide, easy-to-use, access to the archived data will influence 
the capacity and complexity of the system. 

c. The amount of customer data processing beyond Level 0 will drive the 
capacity of the processing resources In the SSIS. 

d. The amount, type, and quality (accuracy, precision, etc.) of 
ancillary data requested by the customer will influence the SSIS 
processing resources significantly. 

e. The level and Implementation plan for autonomy /automat ion provisions 
will have a profound effect on system processing resource 
requirements. The need for autonomy and automation also will 
Influence the basic system architecture and the design implementation 
of subsystems. 
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f. The number and physical distribution of customers will impact the 
networking, complexity of interactive scheduling, and the difficulty 
of dealing with restricted and constrained commands. 

g. The degree to which customers are involved in payload operation, 
especially real time command and monitor and short term schedule 
changes, will drive operations approaches and affect the complexity 
of the scheduling, command management and data handling functions. 

h. The number of customers competing for limiting system resources will 
also Impact the complexity of scheduling and system operation. 

1. The Space Station is expected to undergo extensive growth 

modification and upgrade during its lifetime. New technology must be 
accommodated, providing ready means for its integration. 
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Section 5 

SSIS/SSOS FUNCTIONAL REQUIREMENTS 

This section contains the functional and performance requirements developed in 
Task 1. The SSIS functional requirements are given in Section 5.2, together 
with the performance drivers. The SSDS functional requirements are given in 
Section 5.3. Section 5.4 provides a summary of SSDS functional and 
performance requirements which will have a major effect on the SSDS design. 

The discussion of requirements is divided between the SSIS and the SSDS. 
Discussions of the SSIS, because of its broader scope, will be centered on the 
SSPEs. The SSPEs and their roles have already been identified in Section 
4.2. In Section 5.2, the discussion will cover the functions and key 
performance drivers. Discussions of the SSDS will be centered on functions 
and their decomposition to lower-level functional requirements. 

5.1 REQUIREMENTS ANALYSIS METHODOLOGY 

The functional requirements have been developed from previously published 
documents, from the team data base, and from engineering analysis. Functional 
requirements from the controlling documents (References 1, 2, and 3) were 
identified and entered into the traceability matrix. Details of this process 
are given in Section 5.5, and the complete traceability matrix is given in 
Appendix A. 

In addition, two top-down analyses were conducted in parallel to develop SSDS 
functions. A function tree was developed from prior analyses and logical 
decomposition of functions to successive levels. In parallel, data flow 
diagrams were developed to level 1 for all functions, and to levels 2 and 3 
selectively for some of the complex or critical functions. These parallel 
analyses provided an extremely valuable cross check of the completeness of the 
functions required of the SSDS. 
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The function tree and data flow diagrams were merged to form an integrated, 
hierarchical set of SSDS functions. The function set was checked for 
completeness against the SSIS and SSDS requirements. Each of the requirements 
was mapped to an appropriate function. Where no appropriate function was 
found, a function was added to provide for the SSIS requirement. 

The result is a validated, integrated set of SSDS functions, traceable to the 
requirements and/or analyses that were used to identify the functions. The 
functions are fully responsive to the requirements, and are sufficient to 
perform all identified SSDS operations. 

The final function list is contained in Appendix A, Section A-4. Figure 5-1 
shows the top three levels of the function tree. The number of SSIS 
requirements mapping to each function is shown in parentheses after each 
entry. Host of the functions are supported at this third level by multiple 
requirements. Some of the broader or more generic requirements were mapped 
only to the second level. These requirements also support the lower level 
functions. There are, therefore, many requirements supporting each function 
at the third level, considering the flow down of the requirements from the 
higher level. 

Space Station Program Elements (SSPEs) were identified and allocated to SSDS 
or to the non-SSDS portions of the SSIS in Section 4.2. Requirements 
pertaining to non-SSDS elements and their interfaces were collected by SSPE. 
These requirements are delineated in Section 5.2. Requirements pertaining to 
SSDS elements were collected by SSDS function in the hierarchical structure of 
Figure 5-1. These requirements are delineated in Section 5.3. 

An SSIS Functional Requirements Data Sheet, Figure 5-2, was prepared for the 
functions in the function tree at a level which will support definition of 
design requirements. The functional requirements from these data sheets have 
been entered into a computer-based requirements data base. Output reports are 
found in Reference 14. Key performance requirements identified for those 
functions are collected as SSDS performance requirements in Section 5.4. Only 
those requirements affecting the overall SSDS performance were considered. 
Hence, the performance requirements relate to quantities of data, rates of 
throughput, and timeliness of operation. Wherever possible, representative 
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Numbers in parenthesis refer to the number of requirements traced to the function at the level indicated. 



SSOS FUNCTIONAL REQUIREMENTS DATA SHEET 


Prepared by R—l by; No Oat* 

Function Numhm. Nome: 

Function typo: — Program Phase: Initial Growth 

Description: _ 


Function Soureoa: 


Criticality: Raeorery THno 

Oata Privacy Coda: 

Alarms/ Annunciations: Required? 

Input: *1 #2 

TVpo. IHggor _ 

Source 

Rata _ 

Amt 

Output. 

Typo,THggar _ 

Destination 

Rate 

Amt 

ADDITIONAL REQUIREMENT* 



OEStQN CHARACTERISTICS: 
Data Soureo o: 


Response Time: I/O Delay Alio— Me 

Command/Controfc La— Lo ca tion 

Data Quality: Maximum M Error Rate 

Syndirontiatton With: _ 

System Dependency Code: 

Physical Location Cede: 

Diagnostic a/Solf That Required? 


Repetition Rate 

Data Rag— 

_ k Bytoe Porta h abMHy % In hre 

_ k Bytes No. ot Dtaplaye 

GROWTH CAPABILITY 

Data P rooeeeln y Ina tru ctl on e Per Cycle RepetMen Rate 

Processor Memor y: Program Sto Data Reqmt 

Data S t o r age : Seeondery k Bytes Perteh e MBty % In hr* 

AreMvel — k Byre* No. ot Otoptaye 

Figure 5-2. Functional Requirements Data Sheet 


data are drawn from the Moods Hole Mission Requirements (workshop). 
Engineering estimates are used where no applicable data are found. 


Areas of major design impact which will be noted in the following sections are 


1. Peak data rates, especially for Space Station and POP payloads, will 
drive data throughput, onboard processing, and recording rates. 


2. The combined data rate of the Space Station, COP and POP(s), 

including payload data, are to be transmitted to the ground via 
TORSS. A single Ku-band channel is limited to about 300 Mbps. The 
combined average data rates of these facilities is approaching 300 
Mbps. Hence, these data rates drive the system. 


IOC CAPABILITY 

Otlft NwtnictlMi Nf Cyoftt , 

Proomof MiMiqft PfognMi Ste r . _ L 
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3. The requirement for real time, interactive control of payloads from a 
remote location will affect primarily the scheduling of data and 
command handling resources and communication links. 

4. The data rates and requirements for on-line and short-term archival 
storage combine to drive the design of data storage systems. Onboard 
storage is driven by the scheduling of TDRSS downlinks. In-process 
storage at the Data Handling Center is driven by the requirement for 
12 hours of in-process storage to ensure data delivery. Short-term 
archival storage is driven by the requirement for storage for one 
week after receiving data of satisfactory quality at the customer's 
facility. 

5. The Network Control capability (NCC) must be expanded to accommodate 
the increased TDRSS traffic and to operate the Data Distribution 
Network. Implications to he NCC will be developed in Task 3 and 4. 

5.2 SSIS FUNCTIONAL REQUIREMENTS AND DESIGN DRIVERS 

This section defines functional requirements for the Space Station Information 
System (SSIS) and interfacing Space Station Program Elements (SSPEs). Section 
5.2.1 provides the functional requirements related to the SSPEs and their 
interfaces with SSIS, together with the key requirements driving the SSIS/SSDS 
design. Section 5.2.2 defines customer requirements for standard services 
from the SSIS for those SSIS functions that were determined to be outside the 
SSDS by the criteria in Section 4.2. Customer requirements for the SSDS will 
be addressed in Section 5.3. 

5.2.1 SSPE Functional Requirements 

Each of the Space Station Program Elements (SSPEs) identified in Section 4.2 
are either in the SSIS or interface with the SSIS/SSDS. Functional 
requirements allocated among the SSPEs, SSIS and SSDS, and key performance 
drivers are presented by SSPE in this section. The discussion is restricted 
to those elements identified in Table 4-3 as being in the SSIS, but not in the 
SSDS. 
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5. 2. 1.1 Space Station Payload Requirements 


A) Pavload Functional Requirements 


The Space Station payload interfaces with the SSOS are illustrated in Figure 
5-3. The payloads shall perform the following functions: 


1. Receive customer/operator data and commands from the SSOS. 

a. Oecode/de-encrypt data and commands protected by customer 

b. Execute prestored sequences of commands 

2. Receive time and frequency references 


3. Receive from SSDS standard core and customer data services, for 
example, 

• State vector 

• Ephemerides 

• Pointing angles, etc. 


SSDS 



• Peak Science/Engineering Data Rata = 300 Mbpa 

• Average Science/Engineering Data Rate = 6.9 Mbpe, 1994 

= 54.1 Mbpa, 1997 

• Average Command Data Rate = 2.8 kbps, 1994 

= 3.4 kbps, 1997 


Figure 5-3. SSDS/Payload Data Interfaces 
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4. 


Generate and issue scientific/engineering data stream to the SSDS. 

The payload shall : 

a. Accept and merge Space Station ancillary data 

b. Provide error protection enhancement coding and security 

c. Encrypt as required 

d. Issue payload data stream in appropriate format 

e. Issue payload health and safety status monitors. 

5. Utilize subsystem-protected, reconf igurable resources: 

• Electrical power 

• Thermal control 

• Fluids. 

6. Provide fine pointing, as required by the payload, to supplement 
coarse pointing provided by the Space Station articulating payload 
mount. The customer shall be responsible for developing the 
coarse-pointing reference and delivering pointing requirements to the 
SSDS in the commands from the payload. 

B) Key Drivers 

1. Return Data Rates and Storage. 

The IOC Space Station payload complement may provide an aggragate 
peak data rate of up to 302 Mbps. An estimated IOC (1994 reference 
date) onboard storage requirement of about lO 1 ^ to lO^ 1 bits is 
based on the scenario of a single downlink data burst of about 5 
minutes per orbit with data collected at the 14.9 Mbps (6.4 payload 
data plus 8 voice/video and core) average rate indicated in Table 6-9, 
during a nominal 90-minute orbit. The average data rate peak is 56 
Mbps in 1996. Note that these rates Include a 1.8 "scheduling 
factor" applied to missions with data rates less than 50 Mbps and 
apply to short term averages. See Section 6.4 for further discussion 
of average data rates. The corresponding onboard storage 
requirement Is about 10 10 bits for IOC and 3X10 11 bits In 
1997. These figures Include Space Station core data and voice/video 
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link requirements, and represent a significant impact on the return 
portion of the SSDS data management and communication subsystems. 

2. Forward Data Rates. 

The aggregate IOC forward link command rate is estimated at 3-4 kbps 
average for IOC and growth payloads. The rate does not include 
voice/video or Space Station core requirements. The total potential 
forward rate requirements represent an impact on the forward portions 
of the SSDS data management and communication subsystems. 

3. Scheduling of Resources. 

Mission model analysis yields an average IOC payload power 
consumption on the Space Station of 54 kw, neglecting possible 
redundancy between Comm 1201 and SAAX0401 . The target IOC power 
system delivery is 75 kw of which 25 kw is allocated for SS 
housekeeping. Thus a power resource allocation/scheduling impact on 
the payload complement is indicated. 

A crew of two station specialists and four mission specialists is 
forecast for the IOC Space Station. The crew resource matches the 
estimated payload support requirements on an averaged allocation; 
however, some impact is anticipated on day-to-day operations which 
will require scheduling flexibility. 

5. 2. 1.2 Core System Requirements 

A) Core System Functional Requirements 

The Space Station core systems interfaces with the SSDS are illustrated in 
Figure 5-4. The core systems shall perform the following typical functions: 

1. Maintain Space Station environment and communications links. 

2. Accept and execute SSDS commands for 
a. Orbit maintenance 
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Figure 5-4. SSDS — Core Systems Data Interface 


b. Collision avoidance 

c. Attitude maintenance 

d. Attitude changes to accommodate payloads 

e. Crew health maintenance, recreation, and training 

f. ECLSS reconfiguration 

g. Thermal control subsystem reconfiguration 

h. Power subsystem reconfiguration 

i. Communication subsystem reconfiguration 

j. Resource management 

k. Redundancy management 

l. Maintenance/repair/growth operations. 

3. Generate engineering and status data 

a. Subsystem status 

b. Consumables status. 


4. Generate caution and warning information on equipment operating 
limits and hazards to personnel and vehicle safety, and alert 
operators to unsafe conditions 


169 



B) Key Drivers 


1. Oata Rates and Buffering. 

The high payload data rates will have a significant impact on the 
SSDS/communications subsystem design to provide 

a. adequate data distribution and growth capability, 

b. adequate data buffering and growth capability, 

c. rapid reconfigurability to accommodate operations schedule 
changes 

5. 2. 1.3 Co-Orbiting Platform Requirements 
A) COP Functional Requirements 

The co-orbiting platform(s) (COP) interfaces with the Space Station 
communications system are shown in Figure 5-5. Alternatively, the COP may 
interface directly with TDRSS. The COP shall perform the following functions: 


1. Maintain orbit and attitude per performance requirements 


SSDS 



Peak Science/Engineering Data Rate ■ 1 Mbps 
Average Science/Engineering Data Rate = 1 Mbps 
Average Command Data Rate - 1 kbps 


Figure 5-5. COP, Free-Flyer — SSIS Data Interfaces 
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2. Receive commands and data via TORS or Space Station relay and 

a. Error check data 

b. Validate data and command sources and destinations 

c. Distribute data and commands to individual payloads 

d. Execute orbit, attitude, and resource adjustment commands. 

3. Provide scientific/engineering data stream to co-orbiting platform 
control and customers via TDRSS or Space Station relay, and 

a. Collect scientific/engineering data and merge to data stream 

b. Encode, modulate, and transmit return link data via TORS. 

NOTE: Platform ancillary data are provided to payloads for their own 
merging. 

4. Receive and execute traffic control and proximity operations commands 
from Space Station while in Constellation area. 

5. Receive and execute COP Control Center orbit and attitude commands 
when remote from the Space Station. 

B) Key Drivers 

1. Return Data Rates and Storage Requirements. 

The IOC Co-Orbiting Platform payload data rate varies with mission 
assignment from 1 to 16 Mbps, with growth to about 100 Mbps in some 
mission models. Reference 15 seems to show 1 Mbps peak and average 
with no growth. The onboard storage requirement is estimated to be about 

g 

5X10 bits based on the 1 Mbps average data rate of Reference 15, and of 
a single downlink burst during each 90-minute orbit. The onboard storage 
requirement may apply either to the Space Station, the platform, or both, 
depending on whether the platform transmits directly to TDRS or uses the 
Space Station to relay data. 
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5. 2. 1.4 Co-Orbiting Platform and Free Flyer Control Center Requirements 


A) COP and Free Fiver Control Center Functional Requirements 

The COP and Free Flyer control center interfaces with the Space Station 
Control Center are illustrated in Figure 5-6. Both control centers shall also 
interface with the TDRSS ground station (optional) and the Data Handling 
Center. The COP and Free Flyer Control Centers shall perform the following 
functions: 

1. Plan and schedule Spacecraft operations 

a. Maneuvers 

b. Data links. 

2. Provide mission control data to the SSCC or TDRSS ground station for 
relay to the Spacecraft 

a. Attitude and orbital adjustments for nonproximity operations 

b. Core system data and commands. 

3. Receive engineering data from the Data Handling Center. 

4. Coordinate with the SSCC for rendezvous with the Space Station or OMU 
for payload or Spacecraft servicing and maintenance. 

B) Key Drivers 
None identified. 



Figure 5-6. COP, POP, Free-Flyer Control — SSDS Data Interfaces 
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5. 2. 1.5 Polar Platform 


A) POP Functional Requirements 

The Polar Platform (POP) shall have no direct orbital interfaces with the 
Space Station. The POP shall perform the following functions: 

1. Maintain orbit and attitude to performance and mission requirements. 

2. Receive commands data from Polar Platform Control via TORS 
distribution network and 

a. Error check data 

b. Validate data and command sources and destinations 

c. Distribute data and commands to individual payloads 

d. Execute orbit, attitude, and resource adjustment commands. 

3. Provide scientific and engineering data stream to Polar Platform 
Control Center and customers via TDRSS and the Data Handling Center. 

a. Collect data from the commercial and scientific, and merge to 
data stream 

b. Encode, modulate, and transmit downlink data to TDRSS. 

NOTE: Platform ancillary data are provided to payloads 

for merging prior to downlink. 

The mission model of Referencel5 indicates three POPs, designated POP-1, 
POP-2 and POP-3. 

B) Key Drivers 


1. Return Data Rates and Data Storage Requirements 

The proposed complement of POP payloads has an aggregate peak data 

rate of 393 Mbps for POP-1, 300 Mbps for POP-2 and 76 Mbps for POP-3 

at IOC for each POP. POP-1 data rates grow to 669 in 1995. An 

12 

estimated storage requirement of about 0.5^10 bits for POP-1 and 
10 11 bits for POP-2 and -3 derives primarily from buttering high 


173 


rate missions through the exclusion zone. It was assumed that only the 
highest rate mission would operate through the exclusion zone on any 
single pass. These figures represent a significant potential impact on 
the POP data management and communication subsystem design. 

5. 2. 1.6 Polar Platform Control Center 

A) POP Control Center Function Requirements 

The POP Control Center shall interface with the Space Station Control Center, 
the TDRSS ground station, and the Oata Handling Center. Interfaces with the 
SSCC were shown in Figure 5-6. The POP Control Center shall perform the 
following functions: 

1. Provide scheduling, and operations control for Polar Platform. 

2. Coordinate scheduling requirements for data links with Network 
control center. 


3. Provide scheduling and command management for coordinated payload 
operation between the Space Station and POP. 

4. Receive POP engineering data from the Data Handling Center. 

B) Key Drivers 

None identified. 



The TORS shall be the primary data link for the Space Station and platforms. 
The TDRS shall 


1. Receive reconfiguration commands from White Sands Ground Terminal 
(WSGT) for antenna pointing, frequency, and modulation, etc., to 
transmit and receive payload data. 
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2. Receive and forward link signals, from TDRS ground station. 

3. Retransmit forward link data to the Space Station Communications 
Subsystem, COP Communications Systems (optional). Polar Platform 
Communications System, and other SSPEs such as OMV and OTV when these 
SSPEs are not using other links for communication with the ground 
(users are discriminated by frequencies, polarization, PN code, and 
communication beam pointing). 

4. Receive return link signals from Space Station Communications 
Subsystem, COP Communications Systems (optional), and Polar Platform 
Communications System (users are discriminated by freqencies, 
polarization, PN code, and communication beam pointing). 

5. Retransmit return link signals to TDRS ground station. 

B) Key Drivers 

1 . Return Data Rates . 

The current planning is to effectively dedicate one to three SA 
channels to the Space Station program (SSP). This limits the SSP 
return link data rate to 300, 600 or 900 Mbps total data rate. These 
rates will place some new requirements or limitations on the SSP or 
TDRSS. A single channel limits return data operations of SS, COP, 
and POP and may translate to schedule constraints for payload 
operations. Two or three channels will require new and extensive 
equipment at the ground stations. In addition, the TDRSS is designed 
to operate at steady data rates, necessitating buttering and 
scheduling operation. These impacts will be more severe with the 
implementation of the proposed uplink and downlink video, real-time 
remote payload operation, and audio communicaions. 
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5. 2. 1.8 TDRSS Ground Station Requirements 


A) TDRSS Ground Station Functional Requirements 

The TORSS ground station shall interface with the Space Station Control 
Center, platform control center(s) and the Data Distribution Center. The 
TDRSS ground station shall: 

1. Provide forward link data and commands to TORS: 

a. Receive packetized, framed data from the data distribution 
network 

b. Error check 

c. Provide data accounting 

d. Format and transmit data to TDRS per scheduled time, frequency, 
channel, and modulation. 

2. Provide return link data to the Data Distribution Center 

a. Receive and capture TDRS data 

b. Transmit framed data. 

3. Provide second source tracking data for SSPE navigation. 

B) Key Drivers 

1 . Data Rates . 

The high payload data rates will significantly impact the current 
configuration of TDRSS Ground Station operation. Average data rates, 
including Space Station and platform engineering data and audio/video 
links, will approach 300 Mbps, while peak rates could exceed 600 Mbps. 
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5. 2. 1.9 Space Station Data Distribution Network Requirements 


A) Data Distribution Network Functional Requirements 

The Data Distribution Network interfaces with the TDRSS Ground Station, the 
Data Handling Center, customer facilities, RDCs, and SSPE control centers are 
illustrated in Figure 5-7. The network shall: 


1. Relay forward link commands and data from SSPE and payload control 
centers to the TDRSS Ground Station. 

2. Relay return link data from the TDRSS Ground Station to the Data 
Handling Center. 

3. Distribute return link data to customers, data centers and control 
centers. 


SSDS 



Average TDRSS Downlink Data Rate { 


On-Line Storage 
Off-Line Storage 


= 108 Mbps, IOC 
= 263 Mbps, 1999 
* 10 13 Bits 
■ 2x10 14 Bits 


Customer Peak 
Individual Data Rate 


■ 300 Mbps 


Figure 5*7. Data Network — SSDS Data Interfaces 
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B) Key Drivers 


1 . Data Rates 

The tiigh data rates will require a major increase in the capacities 
of the current configuration distribution network. The average data 
rate between the TDRSS Ground Station and the Data Handling Center 
will approach 300 Mbps, while peak rates may exceed 600 Mbps. The 
aggregate rate from the Data Handling Center to customer and program 
facilities will also approach 300 Mbps. 

5.2.1.10 National Space Transportation System (NSTS1 Requirements 

A) NSTS Functional Requirements 

The NSTS shall support the Space Station program by providing transportation 

services, including 

1. Coordinate rendezvous and berthing with the Space Station. 

B) Key Drivers 

None Identified. 

5.2.1.11 NSTS Mission Control Requirements 

A) NSTS Mission Control Functional Requirements 

The NSTS Mission Control Center shall coordinate operations with the Space 

Station, including 

1. Participate in and support scheduling for NSTS operations to 

transport payloads, SSPEs, crew and logistics supplies between the 
ground and the Space Station. 
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2. Support customer payload/NSTS integration, launch and space 
deployment. 

3. Support SSPE/NSTS integration, launch, and space deployment 
operations. 



None identified. 



Contractor facilities shall interface with the software development 
environment and the integration facilities to coordinate the development and 
verification of applications software and the integration of hardware and 
software into the Space Station system, including the following: 

1. Link to the SOE to utilize the software development and integration 
tools discussed in Section 4. 4. 2. 4. 2. 

2. Link to the Development, Simulation, and Training Facility for system 
electrical and communications interface compatibility. 


B) Key Drivers 


None identified. 


5.2.1.13 Network Control Requirements 



The Network Control Center shall support scheduling of links, including the 
following: 
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1. Plan and schedule network operations, maintenance, and growth. 

2. Provide routing, ID, TORS channel, frequency, PN modulation 
assignments per SSP and other customer requests. 

3. Provide rapid rescheduling of links in support of customer window of 
opportunity or operating requests. 

B) Key Drivers 

1. Data Scheduling 

The high data rates represent a major increase in network performance 
requirements which will necessitate additional communications 
channels and intensive scheduling for data handling, buffering, 
temporary storage and distribution. 

2. Operation/Configuration Scheduling 

An impact is anticipated in responding to SSDS schedule change 
requests to accommodate customer "windows of opportunity". Policies 
must be established supported by realistic reconfiguration 
capabilities. 

3. Customer Real-Time, Remote Operation Complete 

Complete, two-way links between the customer and payload must be kept 
open continuously during real-time operation. Typical command rates 
range up to 100 Kbps, while data rates for most real-time, remote 
operation are under 1 Mbps. 
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5.2.1.14 OTV Requirements 


A. OTV Functional Requirements 

The Orbital Transfer Vehicle (OTV) shall interface with the Space Station. It 
shall be controlled from the Space Station during prelaunch deployment and 
postrendezvous retrieval. The OTV shall perform the following functions: 

1. Communicate with the Space Station 

a. Vehicle status 

b. Payload status 

c. Responses in support of deployment and retrieval operations. 

2. Respond to Space Station control commands. 

3. Berth to the Space Station for checkout and servicing, 
a. Provide diagnostics on OTV system status. 


B) Key Drivers 

None identified. 

5.2.1.15 Customer Regional Data Centers (RPC) Requirements 
A) SSIS Functional Requirements 

The ROCs shall interface with the Data Distribution Network, and shall perform 
the following functions: 

1. Receive, process, and archive payload return data. 

2. Generate catalogs and indexes for archived data and provide 
query/accessibility. 

3. Receive requested core ancillary data and process with payload data. 
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4. Provide SSDS entry point for uplink payload data and commands. 

5. Provide SSDS entry point for schedule, configuration, and core 
ancillary data requests. 

6. Receive dispositions to customer requests. 

7. Provide alternative POCC services to customers. 



Customers may use the support facilities provided by the RDCs or the payload 
operations center for all of their payload operations and data processing. 
Customers may also have their own individual facilities. Those not connected 
to an RDC must provide the RDC resources desired themselves. Those utilizing 
RDC support shall interface with the ROC and shall 

1. Provide SSDS entry point for payload commands and data. 

2. Provide delivery point for payload data (raw, pre-, or fully 
processed) . 

3. Provide SSDS entry point for schedule transactions 

a. Existing schedule examination 

b. Schedule requests/dispositions. 


4. Provide SSDS entry point for core data requests 
a. Core data and processing level. 
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5. 


Process amd archive payload return data. 


6. Generate catalogs and indexes for archived data. 

B) Key Drivers 

None identified. 

5.2.1.18 Deep Space Network Requirements 

A) SSIS Functional Requirements 
The Deep Space Network shall 

1. Provide convnuni cation link to OTV, when outside Space Station and 
TDRSS communications zones. 

2. Provide backup, limited capability communications link for Space 
Station. 

B) Key Drivers 

1 . Data Rates 

In the event that DSN is used as a backup communications link, the 
downlink data sourced -by SS, COP and POP must be configured to meet 
the capability ("85 Mbps) of this network, without causing 
unacceptable impacts on other DSN-dependent space vehicles. 

2. Reduced Coverage 

Use of DSN will impose severe constraints on orbital coverage of 
space elements, limiting communication traffic to the Space Station 
to an average of (TBD). 
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5.2.1.19 Space Station Integration Facilities at Launch Site 


A) SSIS Functions 

The Launch Site integration facilities shall interface with the SSIS for 
requirements and simulations, and shall 

1. Support integration activity of payloads and SSPEs. 

2. Support prelaunch checkout of payloads and SSPEs. 

B) Key Drivers 

None identified. 

5.2.1.20 Alternative Communications Links 
A) SSIS Functions 

The customer may provide alternative communication links from his payload to 
his ground station, either by non-TDRSS satellite link or by direct broadcast. 
The SSDS shall be involved in this transmission only to the extent that 
interference with other SSP communication links is precluded. No independent 
customer command links are anticipated. 

5.2.2 Customer Requirements for Standard Services From the SSIS. 

The SSIS shall provide the following customer standard services exclusive of 
SSDS: 


5. 2. 2.1 Data Processing Bevond Level 0 . The SSIS shall provide or provide 
for the following standard customer data processing services: 

a. Payload data processing to level 1A at a negotiated cost to the 
customer. 

b. Support of production of level IB data. 
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c. Facilities and software routines to support routine analysis of 
payload data for customers. 

5. 2. 2. 2 Data Archiving . The SSIS shall provide, as a standard service, data 
archiving beyond that necessary to ensure the satisfactory delivery of payload 
data to the customer's designated facility. The SSIS shall provide the 
following standard archiving services: 

a. Maintain customer data archives including both level 0 and level 1A 
data as required. 

b. Provide a data search and retrieval system for archived level 0 and 
1A data. 

c. Support long term archiving of level 0 and level 1A data for up to 
two years at a negotiated cost to the customer. 

d. Provide a catalogue of archive data and support interactive customer 
access to the catalogue. 

e. Provide an inventory of level 0 and level 1A data available from the 
archive, the characteristics of the data and sensor system, the level 
of processing and quality of data, associated ancillary data, where 
the data reside, and how to obtain the data. 

f. Maintain a log of customer data transfer requests and their 
disposition, cataloging access information for file transfer and 
producing management reports on the transfer activity. 

5. 2. 2. 3 Provide Access to Space Station Programmatic Data . The SSIS shall 
provide a standard customer service to assist customers in obtaining standard 
programmatic data sets including 

a. Space Station programmatic data, such as the master plan and customer 
payload inventory control. 
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b. Space Station administrative data, such as requirements for 

SSP-customer interfacing, resource utilization reports and billing 
for services rendered. 

i c. Space Station program descriptive data, such as the customer handbook 

and experiment long term planning support. 

5. 2. 2. 4 Data Exchange Among Customers . The SSIS shall provide, as a standard 
service, support for data exchange among customers. This support shall be 
provided at RDC's and other facilities, as appropriate. 

5. 2. 2. 5 Audio and Video Recording and Playback Between Elements . The SSIS 
shall provide, as a standard service, support for the capability for video 
recording and playback between any two elements of the Space Station program 
which are capable of exchanging video recording information. 

5. 2. 2. 6 Long-Term Mission Planning . The SSIS shall provide standard support 
service to customers to assist them in their long-term mission planning. 

These services shall include 

a. Trajectory and rendezvous planning service relating to the Space 
Station. 

b. Space Shuttle rendezvous with the Space Station and projected Space 
Shuttle manifests. 

c. OMV and OTV planned launches and trajectory and rendezvous planning. 

d. Platform trajectory and rendezvous planning services. 

e. Trajectory and rendezvous planning services for other free-flyers. 

5. 2. 2. 7 Remote Workstations at Customer's Facility . The SSIS shall also 
provide, as a standard customer service, a portable remote workstation which 
may be located at the customer's home institution. 
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5.3 SSDS FUNCTIONAL REQUIREMENTS 


This section presents the SSDS functional requirements, as derived from 
References 1, 2, and 3 and the systems analyses of Task 1. The SSDS must 
continue to perform many of these functions in the presence of various 
faults. Specifics are given in the criticality entries of Appendix A, Section 
9. The requirements are organized according to the logical, end-to-end data 
flow structure of SSDS Level 0 data flow diagrams (Figure 4-3) and the 
complete functions list of Appendix A, section 4. 

5.3.1 Functional Requirements to Manage Customer/Operator Delivered Data 
(Function 1 .0) 

The SSDS shall provide end-to-end handling of data originating in customer 
payloads and core systems. Specifically, the SSDS shall 

a. Accept customer data from attached, platform, and free-flyer payloads 
and deliver the data to the customer's designated location. Customer 
data includes payload instrument data, engineering data, SSPE 
ancillary data delivered to the payload, processor dumps, and any 
other data available in or to the payload and required by the 
customer. 

b. Accept core systems data and deliver to the Space Station Control 
Center, Platform Control Centers and Engineering Data Center. 

c. Manage customer payload data. 

d. Manage Space Station and Platform core systems data. 

e. Provide data privacy (definition ). 

f. Time tag customer delivered data. 

g. Manage Space Station Program engineering archival data retrieval and 
delivery to customers. 
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h. Perform data quality analysis at appropriate points throughout the 
system. 

5. 3. 1.1 Additional Functional Requirement to Manage Real Time Data Return 
(Function 1.1) . The SSOS shall provide for the capture, prioritizing, 
routing, dispatch, and packetizing of real-time and near-real -time data to 
customers and station operators, within the constraints of available data link 
schedules. Specifically, the SSOS shall support real-time and near-real-time 
data return by the following services: 

a. Provide real-time, raw payload data to customer. 

b. Relay level-0 payload and monitor data to customers in near real time 
for "quick look" monitoring. 

c. Deliver core system monitor data to ground operators in real time or 
near real time. 

d. Provide real time core data and critical payload data to ground 
operators to enable ground control of critical systems. 

e. Account for real-time and near-real -time data until delivered. 

5. 3. 1.2 Additional Functional Requirements to Manage Delavable Data Return 
( Function 1.2) . The SSDS shall provide for the capture, prioritizing, 
routing, dispatch, and prompt delivery of bulk data from payload and core 
systems to customers and ground operators. Specifically, the SSDS shall 

a. Accumulate bulk data from all payload sources and core systems. 

b. Relay all data to the ground at least once per orbit, consistent with 
scheduling of available data links. 

c. Account for all accumulated payload data until satisfactorily 
received at the customer's designated location. 
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d. Account for all accumulated core data until satisfactorily received 
at the program designated facility. 

5. 3. 1.3 Additional Functional Requirement for Data Distribution (Function 
1.31 . The SSOS shall provide for general preprocessing, capture, routing and 
retransmission of real time, near real time, and delayable data to the 
designated end points. Specifically, the SSOS shall 

a. Provide real-time distribution of real time and near-real -time data, 
including level 0 processing, demultiplexing, buffering, routing, and 
retransmission. 

b. Provide for real-time reallocation of data distribution resources to 
support customer target of opportunity operation. 

c. Provide prompt distribution of delayable data. 

d. Provide temporary storage for data until confirmation of receipt. 

5. 3. 1.4 Additional Functional Requirements to Manage Customer Data (Function 
1.4) . The SSDS shall manage the delivery of requested data to the customer, 
including data interface management, capture, handling, standard processing, 
and accounting of payload and ancillary data. Specifically, the SSOS shall 

a. Acquire core ancillary data, in addition to the ancillary data merged 
into the customer payload data telemetry stream, including: 

(1) Space Station engineering and operations data 

(2) Space Station programmatic, descriptive, and 
administrative data 

(3) Related SSPE data 

(4) Related payload data. 

b. Distribute data to local customers, including audio, video, and 
digital data. 

c. Provide routine customer Level 0 data processing, i.e., data as 
output from the payload with reconstructed sensor formats, time 
ordering, full resolution, and merged ancillary data. 
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d. Provide temporary customer data archives to ensure satisfactory data 
delivery. 

e. Provide customer data accounting until confirmation of satisfactory 
receipt: 

(1) Search, access, and retrieval 

(2) Catalog and inventory Level 0 and 1A data 

(3) Customer data tracking. 

5. 3. 1.5 Additional Functional Requirements to Manage Deliverable Core Data . 
The SSOS shall manage the delivery of core data, including interface 
management, capture, data processing, and data display. Specifically, the 
SSDS shall 

a. Support retrieval of archived core data. 

b. Distribute core data to SSPE elements, including: 

(1) Space Station control center 

(2) Platform control centers 

(3) Free-flyer control center 

(4) OTV control center 

(5) OHV control center 

(6) Engineering data center. 

c. Support delivery of core ancillary data to customers requesting 
specific data. 

d. Provide core data archival storage. 

e. Process and display data for Space Station operators according to 
standard, operator-selected formats. 

5.3.2 Functional Requirements to Manage Customer/Operator Supplied Oata 
(Function 2.0) 

The SSDS shall provide end-to-end handling of commands and data originated by 
customers and operators. Specifically, the SSDS shall 
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a. Provide command, control, and data handling for all customer payloads 
on the Space Station, free-flyers or platforms. 

b. Support remote operation of customer payloads, including real time 
entry of non-restricted commands, executable restricted and 
constrained commands, as processed in functions 3.2 and 3.3. 

c. Support payload operation from the Space Station, ground control 
centers, and customer remote facilities. 

d. Support transmission, reception, and distribution of customer audio, 
video, and digital data. 

e. Support loading of customer provided on-board computers. 

f. Provide the capability for crew or ground to modify, and/or delete 
software within the operating system consistent with operational 
safeguards to prevent impact to station operations. 

g. Permit, with proper authorization, the ground or the payload 
specialists to generate or change, in a real-time mode, payload 
stored, automated command sequences for future execution on board 
platforms or the Space Station. 

h. Provide distribution of commands and serial data loads to subsystems. 

i. Log all commands and maintain a record of command disposition. 

j. Report command and data disposition to the command source. 

k. Verify that all transmitted commands, including those scheduled for 
later execution, are delivered to the customer interface and 
retransmit as required. 

5. 3. 2.1 Additional Functional Requirements to Validate Pavload Commands/Data 
(Function 2.1) . The SSOS shall provide for authorization of commands and 
uplinked data flow to payloads and subsystems. Specifically, the SSOS shall 
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a. Provide a check of operator/customer identification to ensure that 
commands and data are being issued by an authorized customer/operator. 

b. Perform simple syntax checks on the command data header. 

c. Include provisions which prevent unauthorized access to all 
communication links. 

d. Ensure that the operator is authorized to send commands or data to 
the address in the header. 

e. Provide customer command and data entry accountability. 

5. 3. 2. 2 Additional Functional Requirements to Check Pavload Command 
Restriction/Constraint (Function 2.21 . The SSOS shall check each payload 
command, real time or deferred execution, to determine whether the command is 
restricted or constrained. Non-restricted commands and all data shall be 
passed directly to the addressed payload or to the Space Station processor 
scheduling operation of that payload. Restricted and constrained commands 
shall be checked against the appropriate restriction/constraint parameters, as 
outlined in Section 5.3.3. If found to be allowable at their scheduled 
execution time, the restricted/constrained commands will be executed as 
outlined in Section 5.3.3. If commands are not executable, an unacceptibility 
disposition report shall be promptly issued to the command source. 

Specifically, the SSDS shall 

a. Maintain a list of all customer commands indicating which are 
restricted, constrained, and non-restricted. 

b. Provide for identification/differentiation of restricted, 
non-restricted and constrained commands and transmit or route to 
scheduling as appropriate. 

c. Provide disposition of commands and data status to the customer. 
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d. Pass non-restricted commands directly to the customer payload with no 
further checking beyond that of the address of the payload. 

e. Provide command management to protect the system from executing 
inadvertent and unauthorized (and restricted) payload commands that 
may affect crew safety and/or damage the station. 

5. 3. 2. 3 Additional Functional Requirements for Vehicle Core Commands/Data 
(Function 2.3) . The SSDS shall provide for commands and data entered by the 
core system operators. Specifically, the SSDS shall 

a. Verify that the operator is authorized to enter commands or data. 

b. Verify that the operator is authorized to command the system 
addressed. 

c. Check command or data header syntax. 

d. Check commands for restriction or constraints. 

e. Deliver non-restricted, real-time commands and data to their 
destination. 

f. Process restricted or constrained commands as provided in Section 
5.3.3. 

5. 3. 2. 4 Additional Functional Requirements to Provide Ancillary Data 
(Function 2.4) . The SSDS shall make available and provide to customers a 
standard package of Space Station avionics, housekeeping, and special event 
data for inclusion in the payload data stream. The SSDS shall also make Space 
Station ancillary data to customers upon request. Specifically, the SSDS shall 

a. Provide ancillary avionics and housekeeping data (timing, state 

vector, RF communication, System Status, Acquisition of Signal/Loss 
of Signal, moding, pointing, etc.) to attached payloads and customers. 


193 



b. Provide state vector data, attitude, attitude rate, and other special 
purpose information to support individual customer payload functions 
on the Space Station, Space Platforms, satellites, and free-flyers. 

c. Provide ancillary data, when appropriate, to the customer's own 
equipment either on the ground or onboard, and in calibrated 
(engineering) units. 

d. Routinely provide a time reference to an accuracy of 1 millisecond. 

e. Provide orbit position data of a selected reference point for each 
Space Station system element to an accuracy of TBD meters. 

f. Provide attitude data for each Space Station system element to an 
accuracy of TBD degrees. 

5. 3. 2. 5 Additional Functional Requirements to Support Customer System 
Operation (Function 2.5) . The SSOS shall provide standard support functions 
to Space Station, platform and free-flyer payloads. These services shall 
range from data processing to payload checkout, servicing, and operation, as 
described in the ensuing sections. The SSDS shall provide general payload 
support in the following areas: 

a. Provide moderate accuracy pointing of rotating payload mounts, as 
required for attached payloads to meet nominal pointing 
requirements. (High accuracy pointing shall be funded and provided 
by the customer.) 

b. Support cooperative operation with co-orbiting platforms and their 
attached instruments, experiments and payloads. 

5. 3. 2. 5.1 Additional Functional Requirements for Customer Data Processing 
(Function 2.5.1). The end-to-end data support is primarily transparent such 
that as a basic service, the delivered data has the same form and content as 
that issued from the payload. However, some options will be available. 
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Specifically, the SSOS shall provide customers with options for 

a. Payload data storage and processing facilities to support payload 
operation. Access to the services shall be provided through standard 
network interface nodes and attached work stations. 

b. Monitoring payload housekeeping data. 

c. A negotiated quick-look capability for level 0 data. 

All customer unique software must be provided by the customer and must be 
compatible with SSP programming standards. All data processing and handling 
within the SSIS must be according to standard service practices. 

5. 3. 2. 5. 2 Additional Functional Requirements for Customer Payload 
Operation (Function 2.5.2). The SSDS shall provide general support functions 
for customer payloads. Specifically, the SSOS shall 

a. Provide for capability for independent customer operation and 
monitoring of payloads, including ground-to-payload command and 
monitor, consistent with safety and compatible with SSP operational 
constraints . 

b. Provide for activation of payload stored command sequences by 1) time 
comparison with the space element onboard clock (to a resolution of 
1.0 milliseconds), 2) initiation of a payload real-time command, 3) 
another stored command, or 4) event-driven sequences. 

c. Provide health and safety monitoring of payload at customer request. 

d. Provide, as an optional service, customer payload or process control. 

e. Provide customer payload activation/safing services. 
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5. 3. 2. 5. 3 Additional Requirements to Support OTV Operations (Function 
2.5.3). As part of the Space Station growth capability, the Orbital Transfer 
Vehicle (OTV) will be a key element in the transfer of platforms and/or 
free-flying payloads between the Space Station and high-energy orbits. The 
SSDS functional requirements include support of OTV operations, maintenance 
and servicing. Specifically the SSDS shall 

a. Support the integration, checkout and launch of payloads and 
satellites with OTVs prior to transfer to high energy orbits. 

b. Provide for maintenance, servicing, refueling and logistical resupply 
for OTVs. 

c. Support deployment, launch planning, rendezvous planning, and 
retrieval of OTVs. 

d. Relay OTV status to OTV control and customer. 

e. Support handoff of OTV operation to OTV control center. 

5. 3. 2. 5. 4 Additional Functional Requirements to Support OHV Operations 
(Function 2.5.4). The Orbital Maneuvering Vehicle will be operated and based 
at the Space Station and supported by the Space Station. Specifically, the 
SSDS shall 

a. Provide support for the OHV to checkout, maintain, and service 
payloads, satellites, and platforms in low inclination, low earth 
orbits. 

b. Provide support for the OHV to transport co-orbiting satellites and 
platforms between their orbits and the Space Station for servicing. 

c. Provide for storage, maintenance, servicing, and refueling of OMV. 

d. Support deployment, targeting, rendezvous, and retrieval of the OMV. 
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e. Support remote OMV operations for onsite maintenance and servicing of 
satellites and platforms. 

5. 3. 2. 5. 5 Additional Functional Requirements for Customer Payload Checkout 
and Servicing (Function 2.5.5). The SSDS shall support all phases of customer 
payload checkout and servicing. Specifically, the SSDS shall 

a. Support checkout of payloads and satellites after receipt from NSTS. 

b. Provide a standard servicing interface, servicing equipment and EVA 
support equipment. 

c. Provide for maintenance (instrument replacement, etc.), servicing 
(consumables resupply, battery recharge/replacement and checkout of 
remotely located payloads capable of maneuvering themselves to within 
the range of OMV or OTV. 

d. Support the integration, checkout, and launch of payloads and 
satellites with transfer stages for deployment to other orbits. 

e. Provide the resources to support fault detection and isolation to 
customer's payload. 

f. Provide optional payload acti vationAafing services. 

5. 3. 2. 6 Additional Functional Requirements for SSPE Checkout and Servicing 
(Function 2.6) . The SSDS shall support all phases of SSPE checkout, and 
servicing. Specifically, the SSDS shall 

a. Support/interface with SSPEs and customer elements during assembly, 
growth, and servicing. 

b. Support maintenance and servicing of OMVs and platform as an initial 
capability and OTVs as a growth capability including logistical 
resupply. 
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c. Support on site servicing within the capabilities of the OMV and 
OTV . Support servicing of the co-orbiting platform at the Space 
Station. 

d. Support real-time operations, trend analysis, maintenance, and 
checkout of all SSPEs. 

e. Support automatic servicing and performance checkout of the EMUs, 

MMUs and general EVA equipment. 

f. Retain service data and performance trend data for use in defining 
the need for maintenance of all Space Station systems and equipment. 

g. Provide the resources and services to differentiate between payload 
and SSIS faults. 

5.3.3 Functional Requirements to Schedule and Execute Operations (Function 
3.0) 

The SSDS shall provide for the short term (estimated to be one to two weeks) 
scheduling and executing all operations required by the Space Station 
operators and all commands that are either restricted or constrained and 
entered by payload operators. The SSDS schedules shall be based on the master 
plan maintained by the SSDS with inputs from the Space Station Program and 
transmitted through the THIS. Disposition of all commands entered will be 
shown to the operator or customer entering the command. 

5. 3. 3.1 Functional Requirements to Develop Recurring Operations Masters 
(Function 3.1) . The SSDS shall support customer and operator interactive 
development of normal day and major event operations masters. Both shall be 
used as baselines for developing the short term operating schedule for the 
Space Station program elements. 

The SSDS shall support the development of recurring operations masters by 

a. Supporting interactive payload planning and scheduling. 
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b. Integrating customer payload operating requests with Space Station 
resource availability. 

c. Supporting customer requests for non-SSIS resources. 

d. Providing projected data on Space Station resources 

e. Interactively developing payload and Space Station operations 
schedules. 


5. 3. 3. 2 Functional Requirements to Develop Short Term Schedules (Function 
3.2) . The SSDS shall support the interactive development of short term Space 
Station schedules by Space Station system operators and customers. 
Specifically, the SSOS shall 

a. Allow near-term planning entries by the onboard crew. 

b. Coordinate communications allocations for all SSPEs with the network 
control center. Resolve all SSP requirements conflicts. Provide 
type of service, data rates, desired times, and allocations to SSPEs. 

c. Support interactive planning by payload and core system operators, 
including significant orbital parameters, such as time, orbital 
position, and object ephemerides, which may influence payload and 
Space Station operations scheduling. 

d. Provide indications of Space Station and Platform resource 
capabilities and availability to support payload output optimization. 

e. Optimize utilization of Space Station and Payload resources and 
maximization of payload output. 

f. Support rapid replanning to allow customers to take advantage of 
payload opportunities. 

g. Support clearing of restricted and constrained payload commands to 
assist in real-time payload operation. 
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h. Support customer requests for non-SSIS resources. 

i. Develop integrated Space Station Program operations schedules. 

j. Provide accounting of the disposition of restricted and constrained 
commands. 

k. Schedule use of Space Station resources by other SSPE's (e.g. f 
platform. Space Station communications, crew time, etc.) and resolve 
conflicting requests. 

l. Support interactive schedule development with appropriate data 
processing, input/output, and displays. 

5. 3. 3. 3 Functional Requirements to Develop Operating Event Schedule (Function 
3.3) . The SSDS shall prepare an operating event schedule containing the time 
sequenced operating events in the short term schedule, together with the 
commands necessary to initiate these operations. Specifically, the SSDS shall 

a. Check restricted commands and constrained commands for execution 
within the existing short term schedule. 

b. Deliver immediately or incorporate into the operating event schedule, 
as appropriate, those restricted and constrained payload and core 
commands which are executable. 

c. Alert the customer and operator to those restricted and constrained 
payload commands which are not executable in the current short terms 
schedule. Transfer these commands to Function 3.2 for disposition. 

d. Support real-time reallocation of data distribution resources to help 
meet customer priorities. Coordinate communications requirements 
with Network Control. 

e. Store customer payload commands for execution according to a 
schedule, sequence of events, or another stored command. 
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f. Provide accounting of commands incorporated into the operating event 
schedule. 

5. 3. 3. 4 Additional Functional Requirements to Sequence Operations (Function 
3.4) . The SSDS shall provide for the execution of the scheduled operations. 
Specifically, the SSDS shall 

a. Activate stored payload command sequences based on time, sequence of 
events, or other stored command prompts. 

b. Provide for the execution of core commands according to locally 
stored command sequences. 

c. Provide accounting of commands issued. 

5.3.4 Functional Requirements to Operate Core Systems (Function 4.0) 

Core system include both the space and ground elements that are necessary to 
operate the Space Station, Platforms and their associated control and data 
handling program elements. 

5. 3. 4.1 Functional Requirements to Operate GN&C Systems (Function 4.1) . The 
SSDS shall provide the capability to operate the Space Station and Platform 
GN&C systems. The SSDS shall also support the control of proximity operations 
with other vehicles. 

5. 3. 4. 1.1 Functional Requirements for Navigation (Function 4.1.1). The 
SSDS shall perform navigation functions including: 

a. Calculation of the Space Station and Platform navigation state vector. 

b. Calculation of navigation state vectors for Space Station program 
elements. (Space Station only) 

c. Incorporation of navigation state vector information from second 
sources. 


201 



d. Developing approach and departure trajectories for SSPEs. (Space 
Station only) 

e. Oel i very of navigation attitude and attitude rate information to 
customers . 

f. Delivery of navigation information to payloads, including position to 
an accuracy of TBD meters. 

g. Delivery of empherides data to assist in pointing of payloads, 
pointing mounts, and Space Station and platform appendages (solar 
arrays, radiators, antennas, etc.). 

h. Determination of Space Station and Platform attitudes. 

i. Providing the attitude to customers and payloads to an accuracy of 
TBD degrees. 

j Providing an appropriate time tagging for all navigations state data 
to an accuracy of TBD msec. 

k. Propagating the Spacecraft navigation state vector to specific states. 

l. Propagating constellation navigation state vectors to specific 
states. (Space Station only) 

m. Maintaining Space Station, Platform and constellation drag and 
gravity models. 

n. Initiation of scheduling attitude and translation manuevers. (Note: 
these may also be operator initiated.) 

5. 3. 4. 1.2 Functional Requirements for Guidance (Function 4.1.2). The SSDS 
shall provide or support the guidance and orbit control of the Space Station 
and constellation elements. Specifically, the SSDS shall 

a. Provide guidance for SSPE traffic control. 
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b. Provide guidance for approach and departure for SSPEs. 

c. Support SSPE planned operations. 

d. Coordinate reboost maneuvers among payloads and SSPEs. 

e. Manage Space Station and Platform reboost, translation and attitude 
maneuvers. 

f. Plan orbital maneuvers to avoid collisions with orbital SSPEs and 
debris. 

g. Provide orbital re-entry targeting for disposal of SSPEs. 

h. Provide Space Station and tether control when in tethered operations. 

i. Totally or selectively inhibit RCS operation during periods of EVA 
and sensitive payload operations. 

j. Command gimbal position and rate for Spacecraft controlled pointing 
mounts, radiations, solar arrays and communications antennas. 

5. 3. 4. 1.3 Functional Requirements for Attitude Control (Function 4.1.3). 
The SSDS shall support attitude control for the Space Station and selected 
SSPEs. Specifically, the SSDS shall 

a. Establish and command the maintaining of the Spacecraft attitude. 

b. Establish and maintain SSPE relative attitudes. 

* 

c. Provide planning informaion for SSPE operations. 

d. Provide active Spacecraft momentum management. 

e. Coordinate attitude maneuvers with SSPEs and payloads. 

f. Provide dynamic stabilization between flexible body modes and 
attitude control. 
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5. 3. 4. 1.4 Functional Requirements for Traffic Control (Function 4.1.4). 

The SSOS shall support local traffic control in the vicinity of the Space 
Station. Specifically, the Space Station SSOS shall: 

a. Establish and maintain SSPE relative state vectors. 

b. Accept second source relative state vector information. 

c. Propagate constellation relative state vectors. 

d. Monitor SSPE approach and departure trajectories. 

e. Warn operators of unsafe traffic conditions. 

f. Support development of collision avoidance commands. 

g. Execute collision avoidance maneuvers. 

h. Support berthing, docking, and separation operations. 

i. Control OMV operations within the constellation. 

j. Control OTV operations within the constellation. 

k. Schedule rendezvous with satellites and free-flyers. 

l. Control satellite and free-flyer maneuvers during proximity 
operations, via OMV or direct Space Station control of free flyer. 

m. Provide powered guidance support to satellites and free-flyers. 

5. 3. 4. 1.5 Functional Requirements for Tracking (Function 4.1.5). The SSOS 
shall support tracking of objects in the vicinity of the Space Station and 
platforms. Specifically, the SSOS shall 

a. Provide tracking and acquisition for detached vehicles. 
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b. Track all objects near or approaching the Space Station and platforms. 

c. Provide target identification/discrimination and maintain accounting 

for all objects in the tracking zone based on propagated state 

vectors and tracking data. Use state vectors to account for objects 

not resolved because of proximity or obscuration. 

5. 3. 4. 1.6 Functional Requirements for Time and Frequency Management 
(Function 4.1.6). The SSDS shall support the maintenance of time and 
frequency standards for Space Station and payloads. Specifically, the SSDS 
shall 

a. Provide a time reference to an accuracy of at least 1 millisecond. 

b. Provide a frequency reference to at least TBD. 

c. Support the generation of a‘ more accurate time reference for payloads 

which require greater time accuracy. 

5. 3. 4. 2 Functional Requirements to Operate Non-GN&C Core Systems (Function 
4.2) . The SSDS shall support the operation of non-GN&C core systems. The 
support shall include system command and control, data handling, resource 
distribution and control, and monitoring and fault isolation of orbital 
replaceable units. 

5. 3. 4. 2.1 Functional Requirements to Operate Power System (Function 

4.2.1). The SSOS shall support the operation of the Space Station and 
platform power systems. Specifically, the SSDS shall support 

a. Automatic reconfiguration of electrical resources, loads and busses 
to optimize the collection of energy and to distribute electrical 
power to payloads and core systems according to the scheduled demands 

b. Automatic shedding of loads to control power consumption during 
periods of lower than planned energy, including various system faults 

c. Notification to operators of abnormal power conditions. 
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d. Reduction or shedding of power to payloads exceeding prescribed 
limits. 

e. Evaluation of array and projection of energy available. 

f. Array deployment and retraction. 

g. Maintain power to critical systems during all system faults and 

emergencies. (Note: this requirement may be met autonomously by the 

power system.) 

5. 3. 4. 2. 2 Functional Requirements to Operate Thermal Control System 
(Functions 4.2.2). The SSOS shall support operation of the thermal control 
system. Specifically, the SSOS shall support 

a. Control of temperatures in electronic equipment and habitable units 
of the Space Station. 

b. Management of customer payload thermal loads. 

c. Management of Spacecraft thermal loads. 

d. Monitoring and protection of payload thermal interfaces. 

5. 3. 4. 2. 3 Functional Requirements for Structures and Mechanisms Support 
(Function 4.2.3). The SSOS shall provide support for structures and mechanism 
monitoring on the Space Station. Specifically, the SSOS shall support: 

a. Berthing, docking and separation operations for OMV, OTV, NSTS, 
platforms, MMU, and free flyers. 

b. OMV berthing. 

c. OTV berthing. 

d. MRMS operations for construction, berthing and EVA. 
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e. Mechanism control. 


5. 3. 4. 2. 4 Functional Requirements for ECLSS Operation (Function 4.2.4). 

The SSOS shall support the operation of the environmental and life support 
systems on the Space Station. Specifically, the SSDS shall support 

a. The monitoring and regulation of the atmospheric composition in 
habitable modules. 

b. The control of temperature and humidity in habitable modules. 

c. The management of potable and grey water quality. 

d. The detection and control of contaminates and toxic fluids. 

e. The detection of emergency conditions, such as fire, unsafe 
environment, excessive pressure shell leakage, and critical equipment 
failures. 

5. 3. 4. 2. 5 Functional Requirements for Communication (Function 4.2.5). The 
SSDS shall support communications between the Space Station and ground 
elements, between the Space station and constellation elements, between the 
platforms and ground elements and within the Space Station both inside the 
vehicle and during EVA. Specifically, the SSDS shall provide or support 

a. Near continuous ground to Space Station communication by voice and 
video, and data for real-time monitor and control. 

b. Cooperative operations with constellation elements and payloads. 

c. Intrastation and extrastation person to person audio and video 
communication. 

d. Support of remote operations by manipulators and OMV. 

e. Private crew communications between the Space Station and the ground. 

f. Control of OTV and OMV operations. 
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g. Control of free-flyers and satellites during proximity operations, 
via OMV or direct Space Station control of free flyer. 

h. Control of space platforms and platform payloads. 

i. Payload data return from platforms, free-flyers, and other satellites 
in the constellation. 

j. Management of communication links and antennas. 

k. Coordination and sequencing of transmissions. 

In addition to support of payload data return, the SSDS shall not preclude 
independent customer communication for return through satellite links other 
than TORS or direct broadcast to the ground. The Space Station shall 
communicate primarily through the TDRSS satellite system. The communications 
systems shall also provide a contingency link between the Space Station and 
the ground. The SSDS shall provide privacy of all communications to and from 
Space Station and SSPEs. 

5. 3. 4. 3 Functional Requirements to Support Flight Crew Activities (Function 
4.3) . The SSDS shall support the normal operations of the Space Station crew, 
including such activities as health maintenance, recreation, operation of 
Space Station equipment servicing and maintenance of Space Station and payload 
equipment, and servicing and maintenance of satellites and SSPEs. 

5. 3. 4. 3.1 Functional Requirements for Health Maintenance (Function 

4.3.1). The SSDS shall support the operation of the Space Station health 
maintenance facilities. Specifically, the SSDS shall support 

a. The maintenance of crew medical data base and health records. 

b. The downlink of diagnostics for crew health maintenance. 

c. The physiological monitoring and analysis of crew physiological data. 

d. Support of medical diagnostics for the crew. 
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e. The analysis of crew nutrition requirements. 


f. Planning of crew exercise programs to accommodate varying levels of 
strenuous crew activities in operating the Space Station and payloads 

5. 3. 4. 3. 2 Functional Requirements for Space Station Safety (Function 

4.3.2) . The SSDS shall support the maintenance of safe conditions on board 
the Space Station. Specifically, the SSDS shall 

a. Provide for independent detection and control of emergency conditions 

b. Notify operators of the failing of critical systems. 

c. Provide for detection and suppression of fires. 

d. Detect and correct unsafe buildup of toxic or undesirable elements in 
the Space Station atmosphere. 

e. Provide alarm to warn Space Station crewmen of the buildup of toxic 
elements in the Space Station atmosphere. 

f. Monitor all Space Station payloads, systems and coorbiting spacecraft 
status data. The SSDS shall analyze the status data and determine 
unsafe and out of tolerance conditions. The SSDS shall identify 
failed equipment and automatically execute reconfiguration. The 
caution and warning system shall provide alarms and warnings to the 
Space Station crew and present appropriate diagnostic displays. 

5. 3. 4. 3. 3 Functional Requirements to Support Habitability (Function 

4.3.3) . The SSDS shall support the habitability of the Space Station by 
providing commercial video and audio-visual entertainment. The SSDS shall 
also support private crew/ground audio communications. 

5. 3. 4. 3. 4 Functional Requirements for EVA Support (Function 4.3.4). The 
SSDS shall support the safe EVA activities of the Space Station crew by: 

a. Inhibiting RCS firings during EVA activities. 
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b. Controlling manipulator arm movement during EVA activity to avoid 
hazzards to the EVA crew. 

c. Providing O&M procedure support to crewmen during EVA. 

d. Providing support for automatic and semiautomatic servicing and 
checkout of MMU and EMU equipment. 

e. Supporting airlock control. 

f. Supporting EVA monitoring and control. 

5. 3. 4. 3. 5 Functional Requirements for Operations and Procedure Support 
(Function 4.3.5). The SSDS shall provide operations and procedure support to 
the Space Station crew and ground crews in Space Station facilities. 
Specifically, the SSDS shall provide: 

a. Onboard training of crewmen in critical and emergency operations. 

b. Onboard training of crewmen in various maintenance and operating 
procedures for core and payload systems. 

c. Maintenance and troubleshooting procedures support. 

d. Critical or contingency procedures support. 

e. Documentation of IVA and EVA operations data. 

f. Maintenance information recording and retrieval. 

5. 3. 4. 4 Fun ctional Requirements to Provide Customer Avionics Services 
(Function 4.4) . The SSDS shall provide avionics data to meet specific 
customer needs. The support shall include the recording of anomalous events 
taking place aboard the Space Station and platforms which may affect the 
operation or the quality of the data collected by Space Station payloads. 
These reports shall automatically be available to customers whose payloads or 
payload data may be affected. 
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5. 3. 4. 4.1 Functional Requirements for Special GN&C Services (Function 

4.4.1) . The SSOS shall provide special GN&C support services for customer 
payloads, including: 

a. Pointing coordinates for articulating mounts and payloads. 

b. Relative alignment attitude references to payloads. 

c. Ground track determination and forecast to payloads and customers. 

d. Magnetic field and field forecasts to payloads and customers. 

e. Provide range, range rate and attitude of platforms and free fliers 
relative to space station. 

5. 3. 4. 4. 2 Functional Requirements for Contamination Control (Function 

4.4.2) . The SSOS shall monitor the contamination environment in and about the 
Space Station or platform and provide contamination data to customers who 
payloads or payload data may be affected by contamination events. 

Specifically, the SSOS shall 

a. Monitor internal and external contamination sensors and other induced 
environment sensors including electromagnetic vibration, acoustics, 
shock, linear acceleration, temperature, reduced atmosphere, 
contamination, and radiation. 

b. Determine the potential effects of venting, RCS and other burns, and 
water dumps on external payloads. 

c. Monitor the external environment including return flux, number column 
density of IR and other molecules, and discernable particles in the 
field of view of optical instruments. 

d. Determine the potential effects of venting, burns, and water dumps by 
any object in the constellation on all objects in the constellation. 

e. Determine the effects of performing EVA activities on all objects in 
the constellation. 
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5. 3. 4. 4. 3 Functional Requirements for Tracking Services (Function 4.4.3). 
The SSOS shall provide customers and their payloads basic data on the relative 
range and range rate to SSPEs of interest to the customers. 

5. 3. 4. 5 Function Requirements to Monitor and Status System (Function 4.5) . 

The SSOS shall provide general monitoring and status of both core and customer 
systems. 

5. 3. 4. 5.1 Functional Requirements to Monitor Core System Status (Function 
4.5.1). The SSOS shall provide general capability to monitor the status of 
core systems, including: 

a. Monitoring of orbital replaceable units, notifying crew of failed 
units and supporting fault isolation and repair. (Space Station only) 

b. Monitoring and control of fluids and fluids status. 

c. Monitoring of Space Station, platform and ground station system 
performance. 

5. 3. 4. 5. 2 Functional Requirements to Monitor Customer System Status 
(Function 4.5.2) . The SSDS shall provide general customer system monitoring 
support, including 

a. Monitoring of fluids status. 

b. Monitoring of payload status indicators such as voltage and current. 

c. Monitoring of customer and customer support ground systems such as 
data links, data processing equipment and data storage equipment. 

5.3.4. 5.3 Functional Requirements for Mass Properties Configuration 
Updates (Function 4.5.4) . The SSOS shall provide up-to-date data on mass 
properties and related configuration information for the Space Station. Data 
to be provided includes: 
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a. 


Mass 

b. Moments of inertia 

c. Area and area distribution 

d. Location of payloads 

e. Location of other key equipment. 

5. 3. 4. 5. 4 Functional Requirements for Diagnostic Support (Function 

4.5.5) . The SSOS shall provide general diagnostic support for the Space 
Station operators. Support categories include 

a. Schematic presentations showing key status and performance data of 
various Space Station equipment. 

b. Expert system analysis to support the operation and control of the 
Space Station. 

c. Trend analysis to indicate the probable performance of various Space 
Station systems and potential for failures or less than satisfactory 
performance. 

5. 3. 4. 5. 5 Functional Requirements for System Test and Evaluation (Function 

4.5.6) . The SSOS shall support the test and evaluation of both payload and 
Space Station systems. This support shall include both prelaunch and on-orbit 
procedures. Payload test data shall be delivered to the customer. System 
test data shall be delivered to the Space Station operators and to the 
affected contractors. Operators shall be supported by procedures and by 
indications of satisfactory system performance. 

5.3.5 Functional Requirements to Manage Facilities and Resources (Function 
5.0) 

The SSOS shall provide for the management of facilities identified as being in 
the SSOS. This management shall include the protection of proprietary 
information, the management and distribution of data bases, the support of 
access to subsystems status, and the management of facility data processing 
equipment. 
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5. 3. 5.1 Functional Requirements to Manage Flight System Facilities (Function 
5.1 ) . The SSOS shall provide the facilities necessary to manage the flight 
system data base,- manage the flight system data processing equipment, and 
prepare displays and controls for operator interfacing. Specifically, the 
SSDS shall provide for 

a. Command and control and data handling from all habitable Space 
Station modules. 

b. Management and delivery of core data files to appropriate data 
processors and to operators. 

c. Monitor and control data processing equipment. 

d. Management of facilities supporting payload data processing. 

e. Rate buffering for customer delivered data. 

f. Support of fault detection and isolation for data processing 
equipment. 

g. Reconfiguration of data processing equipment to meet changing demands 
and to recover from equipment failures. 

h. Monitoring and protecting of data system interfaces. 

i. Measurement and control of available data resources. 

j. Monitoring of payload consumption of critical Space Station resources 
and issuance of reconfiguration or disconnect commands to the core 
subsystems. 

k. Support for onboard separation of customer stored command sequences. 

l. Storage of customer command sequences. 
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5. 3. 5. 2 Functional Requirements to Manage Ground System Facilities (Function 
5.21 . The SSDS shall provide for the management of the Space Station Program 
Ground System facilities, including SSDS data base management, Ground System 
schedule managment, management of displays and controls for ground operators, 
and global facilities management coordination for all SSDS data processing 
facilities. Specifically, the SSDS shall provide for 

a. SSOS data base file management and delivery. 

b. Status inset end-to-end communications system. 

c. Status at ground data processing equipment. 

d. Reconfiguration of ground system data processing equipment to meet 
changing demands or to recover from equipment failure. 

e. Monitoring and protection of ground data system interfaces. 

f. Customer systems statusing. 

g. Real-time reallocation of data distribution resources to meet 
real-time changes in customer requirements. 

h. Support uplink of developed software for both customer systems and 
core systems, including customer stored command sequences. (Note: 
Customer command sequences may also originate from the customer's 
facility and be transmitted as payload data or may be originated by 
an onboard mission specialist.) 

5.3.6 Functional Requirements to Develop, Simul ate. Int egrate, and Train 
(Function 6.0) 

The SSDS shall provide a robust environment for development and integration of 
hardware and software and the training of crew, operators, and customers. Not 
the least of this environment will be simulations of sufficient fidelity to 
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support verification of 1) physical and logical interfaces, 2) software 
performance, and 3) end-to-end data transfer. The SSOS shall 

a. Provide the capability to ensure that all modifications and upgrades 
function properly and are compatible with interfacing hardware and 
software components. 

b. Provide to the customer those common tools necessary to permit 
adequate verification and validation of customer hardware and 
software with the standardized SSDS interfaces. All tools necessary 
for payload performance verification, over and above interface 
verification, will be the responsibility of the customer. 

5. 3. 6.1 Additional Functional Requirements To Interpret Model Requests 
(Function 6.1) . The SSOS will provide a configurable integration system of 
sufficient breadth to support all standard customer, crew, and contractor 
requirements. A primary task of the system mechanization will be the 
processing of system requests to determine and issue the reconfiguration 
requirements to the overall hardware and software elements of the system. The 
system will operate interactively with the using agency to support these 
requests. Specifically, the SSDS shall 

a. Provide user-friendly remote access using menu-driven prompts to set 
up the simulation for use by the customer. 

b. Provide a choice of subsystem models ranging from static models to 
highly dynamic models subject to customer provided boundary 
conditions. Models of SSIS subsystems, ancillary data blocks, and 
operational constraints are some of the required models. 

c. Accept characteristics of equipment and/or software to be supplied by 
the user. 

d. Display resource availability. 

e. Display current system interconnection. 

f. Display system schedules. 
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5. 3. 6. 2 Additional Functional Requirements To Develop Communication Model 
Configuration (Function 6.2) . The integration system communication links to 
the operational system will operate in conjunction with a configurable 
communications element simulator. Specifically, the SSDS shall support 
integration testing to: 

a. Verify customer payload to communication system interfaces. 

b. Provide for external interfaces to verify end-to-end customer data 
throughput. The data shall be verified from the payload through 
delivery as a completed data set. The customer shall provide the 
source of the payload data. 

c. Select system simulations to be used, including data entry and 
reception models. 

5. 3. 6. 3 Additional Functional Requirements To Simulate Space Station 
Communication Elements (Function 6.31 . The communications simulation shall 
include communication links to the operational system. Specifically the SSDS 
shall 

a. Provide for maximum use of flight system capability to reduce the 
requirements for ground support equipment and other support during 
ground testing. 

b. Accept payload test data from the Space Station or the customer 
payload in the simulator and deliver to the customer for verification 
of communication links. 

c. Accept payload commands from the customer and deliver to the Space 
Station payload in the simulator for verification of command link. 

d. Provide the interfaces to allow a verification of (segmented as 
necessary) end-to-end customer data throughput. 

e. Configure the communications simulation. 
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f. Perform simulations of communications system elements. 

g. Interface with other simulations, as required to incorporate 
communications interfaces and simulations. 

5. 3. 6. 4 Additional Functional Requirements To Develop Hardware Integration 
Configuration. (Function 6.4) . This funtion derives and issues the hardware 
simulation configuration requirements. The SSDS shall 

a. Select a standard data interface for payload or contractor hardware 
connection. 

b. Select simulation models of the SSOS interaction with the hardware to 
verify hardware functions. 

5. 3. 6. 5 Additional Functional Requirements To Simulate Space Station Elements 
(Function 6.5) . The SSDS shall provide the resources to support customer and 
contractor hardware integration. Specifically, the SSDS shall 


a. Provide standard data interfaces for mounting customer payloads and 
contractor hardware at the simulator. 

b. Provide for remote hardware data interfaces at the customer or 
contractor facility. 

c. Provide the facilities and resources to support Space Station 
equipment verification testing to ensure that all elements and 
payloads are launch ready. 

d. Accept test data from the customer payload and return to the customer 
for verification. 

e. Support verification and compatibility testing of standard ancillary 
data formats and information content. 

f. Provide simulation functions to enable the validation of operational 
procedures and software to the limits of expected flight constraints. 
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g. Support software development for the customer testing and execution 
of customer analysis programs. 

h. Develop simulation models and deliver to contractor to support Space 
Station hardware integration at the contractor's facility. 

i. Develop simulating models and deliver to customer to support payload 
integration at the customer's facility. 

j. Verify that interfacing hardware meets data interface standards. 

5 - 3 - 6 - 6 Addition al Functional Requirements To Develop Software Integration 
Configuration (Function 6.61 . The SSDS shall provide the facilities and 
resources to support customer and contractor software integration. 
Specifically, the SSDS shall 

a. Provide a remotely accessible, real-time simulation of SSIS software 
services to the extent necessary to verify the SSIS to Payload 
software interfaces at the customer's facility. 

b. Provide user-friendly remote access using menu-driven prompts to set 
up software integration simulations for use by the customer. 

c. Provide simulation functions to enable the validation of operational 
procedures and software to the limits of expected flight constraints. 

5. 3. 6. 7 Additional Functional Requirements To Simulate Space Station 
Processors (Function 6.7) . The SSDS shall provide Space Station software 
simulation and processor emulation in support of software development, 
integration, and performance simulations. Specifically, the SSOS shall 

a. Support the capability for customer payload specialists to develop 
and verify payload stored command sequences for future execution 
onboard the platforms or the Space Station, especially those 
requiring core system interaction. 
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b. Provide a remotely accessible real-time simulation of SSIS software 
services to the extent necessary to verify the following 
SSIS-to-payload software interfaces at the customer's facility: 

1) Protocols at all software layers 

2) Full breadth of customer command capability 

3) Standard ancillary data formats and information content 

4) SSIS/DBMS interaction with flight and ground customer 
application software. 

c. Configure system data processing simulations. 

I 

d. Simulate command and data management. 

e. Simulate system operation. 

f. Verify that software packages meet interface standards. 

5. 3. 6. 8 Additional Functional Requirements to Conduct Training Exercise 
(Function 6.8) . The SSDS shall interpret training requests and provide the 
appropriate training operation conf iguration; Specifically, the SSDS shall 

a. Provide capability to receive new or revised training material 
transmitted from the ground. 

b. Provide preflight training on systems management, trajectory and 
navigation support, activity planning, logistics, communications, 
emergencies, proximity and manipulator operations, and the onboard 
training system. Extensive preflight training will be limited to 
critical systems functions with an emphasis on part-task training. 

c. Configure on-orbit training to support crew special and emergency 
operations. 
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d. Configure ground based training to support all aspects of crew 
training. 

e. Select procedures, simulations, and interfaces to be used. 

f. Provide on-board accessible training capabilities to maintain 
critical crew skills, to maintain crew quick reaction capability for 
emergency procedures and contingencies, and to support in-flight 
operation and maintenance tasks, both IVA and EVA, for payloads and 
core system operation. 

g. Provide preflight training which is limited to critical system 
functions with emphasis on part-task training. 

h. Optimize crew interfaces and establish training commonality, 
providing common training software packages and video tapes for 
ground training facilities and on-board training utilizing Station 
training capability, using new or revised training lessons 
transmitted from the ground. 

i. Provide CCTV for crew training. 

j. Provide mission and payload independent customer training facilities 
necessary to adequately train the customers in operation of the SSIS. 

k. Provide high fidelity simulation of payload work stations. 

l. Provide for training in the integrated operation of multiple payloads. 

m. Configure training simulations. 

n. Simulate system operation. 
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5. 3. 6. 9 Additional Functional Requirements to Develop Software (Function 
6JL The development function shall include services to assist both 
contractors and customers in software development. The software support 
environment shall primarily support contractor applications software 
development and integration. The SSDS shall also support the development of 
software for customer payloads and for use in the simulator. The SSDS shall 

a. Provide software programming language support. 

b. Maintain a library of standard routines for use by customers, 
contractors, and simulation software developers. 

c. Provide simulation functions to validate customer and contractor 
software. 

d. Support onboard or customer facility generation of customer stored 
command sequences. 

e. Support onboard software development for modification by the Space 
Station crew. 

5.3.7 Functional Requirements to Support Space Station Program (Function 
7.0). 

The SSDS shall interface with the SSIS and THIS to provide SSP programmatic 
support. 


5. 3. 7.1 Functional Requirements to Maintain Integrated Logistics Plan 
(Function 7.1) . The SSDS shall monitor payload and core systems consumables, 
repair parts and spare parts. The logistics planning shall develop 
requirements for timely resupply. Logistics support requirements shall be 
delivered to TMIS for incorporation into the SSP plans. 

5. 3. 7. 2 Functional Requirements to Log Customer Usage of the System (Function 
7..JL1* The SSDS shall be responsible for logging all customer usage of SSIS 
services. Reports shall be presented to the customers, and chargeable service 
data shall be delivered to the TMIS. 
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5. 3. 7. 3 Functional Requirements to Maintain Technical Documents (Function 
7.31 . The SSOS shall be responsible for maintaining Space Station, SSOS 
facilities, and payload operations and maintenance manuals. Satellite service 
procedures shall be supplied by the SSP, with updates based on servicing 
experience supplied through the SSOS. Manuals required onboard shall be 
available to customer guest operators and crew via CRT display. 

5. 3. 7. 4 Functional Requirements to Control Inventories (Function 7.41 . The 
SSOS shall be responsible to status inventories of materials, repair parts and 
spares for SSOS facilities, the Space Station, and payloads. The primary 
responsibility for inventory control will rest with the SSP. Inventory status 
will be communicated through the TMIS. 

5. 3. 7. 5 Functional Requirements for Configuration Management (Function 7.51 . 
The SSOS shall be responsible for monitoring the mass properties data required 
to perform avionics calculations. Basic data are provided through the TMIS. 
The SSOS will keep the mass properties data base current, including effects of 
docked vehicles and tethers. 

5.3.8 General Oesign Requirements 

5. 3. 8.1 SSOS Operational Lifetime. (RFP C-4-2.1.4.11 The SSOS shall have the 
ability to remain operational indefinitely through periodic inspection, 
maintenance, and replacement of components. Servicing intervals for the 
platforms shall be as specified in paragraph 3.4 of attachment C-3. 

5. 3. 8. 2 SSOS Modular design commonality growth. (RFP C-4-2.1.51 The SSOS 
shall be designed to facilitate system growth through use of modular and 
subsystem design. The SSOS shall employ common hardware, software, and 
standard interfaces which optimize benefit to the SSP. 

The SSIS/SCS shall be designed to be modularly expandable/replaceable. It 
shall permit customer and system technology upgrades, capability upgrades, and 
function migration between ground and space. (CRSS-1.1.6) 
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5. 3. 8. 3 SSDS Technology accommodations. ( RFP C -4-2. 1.6) The SSDs shall be 
designed to accommodate the incorporation of new technology as appropriate to 
optimize benefits to the program. 

Technology accommodation. The SSDS shall accommodate new technology without 
requiring major redesign or reevaluation or disruption of services of the 
system to the extent practical. (RFP C-4— 2 .5.1 . c ) 

5. 3. 8. 4 SSDS Autonomy/Automation (RFP C -4-2.1 .7.2.1 .81 A phase degree of 
on-orbit autonomy shall be provided consistent with evolving systems and 
operations requirements, cost, and applicable evolving technologies. Platform 
design shall facilitate autonomous operations between scheduled servicing 
period but shall not preclude ground intervention. 

A phased progressive automation of both flight and ground elements shall be 
accommodated consistent with evolving system requirements, cost, applicable 
technologies, and the NASA Automation and Robotics Plan (to be supplied at 
CSD, April 1985). 

5. 3. 8. 5 SSDS Maintainability. (RFP C-4-2.1.91 SSDS hardware and software 
shall be designed: 

To facilitate on-orbit and ground maintenance, inspection, and repair with 
maintenance performed on-orbit to the Orbital Replaceable unit (ORU) level. 
(RFP C -4-2.1 .9. a) 

Such that all reasonable failures or damage is restorable or repairable. 

(RFP 4-2-1. 9. b) 

To be capable of undergoing maintenance without the interruption of critical 
services and with minimum interference with other SSDS operations. 

(RFP C -4-2.1 . 9 .d) 

Such that preventive and corrective maintenance activities for the Space 
Station system minimize the use of available crew time. (RFP C-4-2.1.9.h) 
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5. 3. 8. 6 SSDS Reliability. (RFP C-4-2.1 .10) Reliability programmatic 
requirement shall be as specified in SSP J8400001, "Product Assurance 
Requirements for the Space Station Program." Reliability design requirements 
for the SSP are as follows: 

Failure tolerance. (RFP C-4-2.1 .10.1 ) Safety critical and mission critical 
subsystems are those whose function, if lost, would produce a condition 
endangering on-board personnel or prevent the accomplishment of a critical 
mission objective. Safety and mission-critical subsystems shall be designed 
to be fail-operational/fail-safe/restorable, as a minimum (except primary 
structure and pressure vessels in rupture mode and premature firing of 
pyrotechnics). This criteria applies during all operational phases except 
initial assembly and maintenance. For applicable subsystems, some degraded 
performance following the first failure is not precluded by the 
fail-operational/fail-safe requirement. During assembly and maintenance, 
critical SSDS subsystems shall be fail-safe as a minimum. Other SSDS 
subsystems and ground support hardware shall be designed to be 
fail-safe/restorable. Subsystems in pressurized modules shall be able to 
return to normal operation after the module has lost pressure on-orbit and 
been repressurized. 

Redundancy (RFP C-4-2.1 .10.2) Redundancy verification. Redundant functional 
paths of subsystems shall be designed to permit verification of their 
operational status in flight without removal of ORUs. (RFP C-4-2.1 .10. 2. a) 

Failure propagation. (RFP C -4-2-1 .10.3) Subsystem design shall be such that 
one failure does not cause additional failures. 

Separation of redundant paths. (RFP C-4-2.1 .10.4) Alternate or redundant 
functional paths shall be separated or protected such that any event which 
causes the loss of one functional path will not result in the loss of the 
alternate or redundant functional path(s). 

5. 3. 8. 7 SSOS Safety. (RFP C-4-2.1. 11) The safety programmatic requirements 
shall be as specified in "Product Assurance Requirements for the Space Station 
Program", J4800001 . The SSDS and ground systems shall meet the safety design 
requirements specified herein. 
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The following safety requirements are applicable to all SSP systems, 
subsystems, and operations. These requirements apply under worst-case natural 
and induced environments. 

Override capability. The crew must be able to override any automated safing 
or switchover capability of functional paths. All overrides shall be two-step 
operations with positive feedback to the initiator that reports the impending 
results of the override command prior to the acceptance of an execute 
command. Separable functional paths shall be used to prevent single failures 
from causing both an unintended auto switchover and the inability to override 
it. (RFP C-4-2.1 .11. 4. a) 

Command/control redundancy. Redundant accommodations for complete command and 
control of the Space Station shall be provided in separate pressurized 
volumes. Functions to reestablish pressure in a module shall be operable by 
pressure-suited crewmembers. (RFP C-4-2.1 .11 .4. b) 

5:3. 8. 8 SSDS Privacv/Securitv Information privacy. The SSDS shall provide 
data partitioning and protection to assure mission success and accommodate 
data privacy, commercial proprietary data, and security measures. 

(RFP C -4-2. 2. 2. 5.1 .b) 

The SSDS design shall provide for crew members to communicate privately with 
the ground. This private communication link shall include both audio and 
video data. (RFP C-4-2.2.6.2. j) 

The SSIS/SCS shall permit the customer to perform private operations covering 
commanding, data transmission, and in Site hands-on operations. (CRSS-1.1.7) 

5. 3. 8. 9 SSDS Standards Standardized language, protocol, format, and 
transmission rates for all SSOS and all SSDS subsystems. (RFP C-4-2.2.5.3.g) 

As a first preference, customer interface standards shall be defined in 
accordance with the International Standards Organization (ISO) seven layer 
model for Open System Interconnect (OSI). ( CRSS02 .1.1) 
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The SSIS/SCS shall use, for each of the seven layers, existing internationally 
accepted standards as first priority followed by new standards development 
(within the OSI model framework). (CRSS-2.1 .1 .1 ) 

The customer interfaces defined within the first three layers of the OSI model 
shall conform to standards defined and controlled by sources such as: 

NBS, National Bureau of Standards 

ANSI, American National Standards Institute 

ECMA, European Computer Manufacturing Association 

CCIUTT, Consultative Committee for International Telegraph and Telephone 

EIA, Electronic Industry Association 

CCSDS, Consultive Committee for Space Data Systems 

IEEE, Institute of Electrical Electronics Engineers 

(CRSS-2.1 .1) 

When practical, appropriate standards from these sources shall be used at 
higher layers of the OSI model. (CRSS-2.1 .2.1 ) 

The SSIS/SCS shall obtain and/or develop standards for customer interfaces in 
candidate areas such as software, critical/limited payload health and safety 
monitoring, man-machine interfaces, uniform system control and operational 
language for Payload test/checkout and operations, command generation, time 
code, attitude and position data, pointing coordinate systems, data base 
management systems, graphics displays, data handling/archiving/distribution, 
documentation, configuration control, cost accounting, data system 
requirements definition, operation audit trail, etc. When new customer 
standards are proposed, the SSIS/SCS shall present these standards on behalf 
of all customers. (CRSS-2.2.1) 


227 



5.3.8.10 SSDS Customer/Operations Support The SSOS shall support a 
user-friendly language for the man/machine interface. The language shall be 
capable of interfacing between man and machine for communications, display 
generation, monitoring, checkout and control during all phases of development 
and operations. (RFP C-4-2.2.5.2.c) 

The SSIS/SCS shall be designed to provide simultaneous premission, mission, 
and postmission customer support. (CRSS-1.1.2) 

The SSIS/SCS shall be designed to reduce requirements placed upon customers by 
minimizing the complexity of interfaces, avoiding duplication of payload 
options, and by providing a user friendly environment for the customer during 
the payload life cycle. (CRSS-1.1.4) 

The SSIS/SCS shall maximize the use of standard interfaces throughout the 
system. (CRSS-1.1.5) 

The SSIS/SCS system design and operation shall be user friendly. 

Examples of "user friendly" features are: 

• Interactive SSIS user terminals 

• "Prompts" user through an operation 

• Informs user of errors made and where they were made 

• Provides a "help" function to assist user when necessary 

• Protects against customer deduced system crashes 

• Continually informs user of what operation is taking place (never 
displays a blank screen) 

• Allows a skilled user to bypass menus, etc. for more rapid operation 
(CRSS-1 .1.8) 

The SSIS/SCS shall enable a customer to control his payload in functionally 
the same manner as if the payload were in his laboratory. (CRSS-6.1 .3,1 .1 .3) 

The SSIS/SCS shall make payload information available to the flight crew or 
payload specialists via computer terminal equipment with keyboard entry/ 
display and generation of text/graphics display. A hard copy generation 
capability shall be provided. (CRSS-6.4.1) 
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This equipment shall be functionally equivalent to commercially available 
equipment to the maximum extent reasonable. (CRSS-6.1 .4.2) 

The SSIS/SCS shall be designed to support customer payload operations 24 
hours/day, 7 days/week. (CRSS-1.1.1) 

5.3.8.11 SSOS Communications TORSS shall be the primary means of Orbital 
Maneuvering Vehicle (OMV), platform and Space Station payloads space to ground 
communications. All payload (requiring TDRSS services) downlink/uplink 
communication rates shall be consistent with the TORSS limitations, as defined 
in the latest users guide, [“TRDSS User's Guide", Revision 5, March 1984, 
(J8400026)]. The Space Station and platform(s) shall be capable of 
transmitting/receiving customer data to/from the ground through TORSS 
consistent with requirements in Reference 19, Appendix A. All customer 
requests for uplink/downlink support will be managed by the SSIS in 
coordination with the TDRSS Network Control Center (NCC). (CRSS-0.1) 

Communications between the ground and the Space Station and Space Platforms 
shall be through the Tracking and Data Relay Satellite System (TORSS) or its 
replacement system. The use of the maximum TORSS transmitted and received 
data rates over both the Ku-band single access link and the S-band single 
access link shall be provided for. Data rates in excess of the maximum shall 
be transmitted as Individual data streams to the ground Independent of TORSS 
and TOAS using payload providing systems. Provisions shall be made for a 
contingency command and telemetry link to the ground from the Space Station 
and Space Platforms. (RFP C -4-2.2. 6. 2. g) 

The SSIS/SCS shall permit an alternate communication link consistent with 
Space Station Program policies, implemented by the customer independent of 
TROSS/TOAS. (CRSS-1 .1.10) 

The SSIS/SCS shall support the customer requirements for communication rates 
up to those overall design constraints described in Reference 19, Appendix A. 
(CRSS-5.1 .3) 
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The SSIS/SCS shall permit customer provided direct Space Station 
System-to-Ground transmission links subject to Space Station System 
constraints and restrictions. (CRSS-5.1.5) 

Standard telecommunications interfaces shall be provided enabling customers to 
receive and transmit video, voice, data, and commands via customer supplied 
equipment. (CRSS-5.1.8) 

The SSIS/SCS shall provide sufficient video channel(s) (uplink and downlink) 
to the Station for use by all customers on a scheduled basis. (CRSS-5.2.9) 

The uplink and downlink shall support transmission of command and data 
information between customer's ground and onboard equipment in a transparent 
manner. Restricted and constrained commands shall be identified and 
transmitted or inhibited by the SSIS. (CRSS-6.1 .3.1 ) 

5.3.8.12 SSDS Workstation The SSIS/SCS shall provide these work stations at 
three locations as follows: 

A work station in the customer control facility which will be available to 
individual customers. (CRSS-6.1 .5.2.1) 

A flight station which will be used by the onboard Space Station crew or the 
onboard payload specialists. This station shall provide for onboard time 
shared use of text and graphics type keyboard display terminals for use by 
crew or customer's onboard representative in controlling the operations of the 
customer's onboard hardware. This terminal shall be functionally identical to 
a commercially available text and graphics terminal and shall interface to the 
customer's payload via a transparent data link. (CRSS-6.1 .5.2.2) 

The SSIS/SCS shall provide onboard workstations capable of supporting mission 
planning, scheduling, and system resource allocation as stated Paragraphs 
7.2.1 and 7.2.2 of reference #2. (CRSS-7.2.3) 

Operational interfaces. The onboard operational interface to the OHS shall be 
through Multipurpose Applications Consoles (MPAC) and the distributed computer 
processing system. (RFP C -4-2. 2. 5.1 .a) 
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5.4 REQUIREMENTS ORIVERS 


The team has reviewed the functional and performance requirements generated in 
Task 1 and identified those functional and performance requirements which are 
expected to have a major impact on the design of the SSOS. These requirements 
and their expected impacts will be discussed in the subsections of 5.4. 

5.4.1 Impacts of Overall Data Rates 


Data rates for the primary SSPEs are developed in Section 6.4. Data rates are 
shown in Figure 5-8. The aggregate average payload data rate of the Space 
Station, COP and POP begins in 1992 at about 100 Mbps. There is an additional 
estimated overhead of about 8.6 Mbps for voice, video, and spacecraft 
engineering data. As the number of payloads on orbit increases, the aggregate 
data rate increases to a peak of 253 Mbps in 1999. With voice, video, and 
engineering data, the average data rate is about 263 Mbps. These data rates 
do not include the additional transmission requirements necessary to achieve 
the bit error rates of 10 6 required by the Space Station program. The 
current KSA channel capability for TDRSS is 276 Mbps. With current coding. 
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the effective capacity is 150 Mbps. Hence, lower coding overheads, lower data 
rates and/or multiple TORSS channels are required for the combined 
transmission, especially after 1999. The level of coding and overhead to be 
incorporated will be developed in Task 4. 

It is conceivable that the peak payload data transmission for the combined 
Space Station, COP and POP could be scheduled so that there is no simultaneous 
transmission of information on two KSA channels. There is some evidence 
supporting a probable lower average data rate for some of the highest data 
rate instruments in the Space Station program, especially those of POP-1. 

With these caveats, it seems possible that the combined data rates of the 
Space Station program will be consistent with the use of an equivalent single 
KSA channel. If this is indeed the direction that the program takes, data 
rates will become design drivers in the following areas: 


• Scheduling of facilities and communication links from the space 
vehicles through the TORSS to the Data Handling Center. 

• Providing adequate onboard storage for data to buffer the data 
collection and transmission according to the combined transmission 
schedule to TORS. 

• Performing level 0 data processing in real time at 300 Mbps with data 
recording and error detection. 

• Supporting real-time error correction processing on the raw data. 

13 

• On-line storage of up to 10 bits of data to support the 12 hour 
on-line storage requirement. 

• Sorting, repackaging, routing, and transmission of individual 
customer data packages. 

• Distribution of data rapidly enough to receive confirmation of 
satisfactory transmission within the 12 hours on-line storage 
duration. 
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If the program chooses instead to go to simultaneous use of parallel TORS 
channels, the impact on the design will be felt primarily at the TORS ground 
station and in the communication from the ground station to the Data Handling 
Center. The TORS ground stations will have to be upgraded to receive 600 Mbps 
transmission rates. The ground station must later buffer these transmission 
rates over the entire period of transmission overlap, or it must upgrade its 
retransmission facility to route the full 600 Mbps transmission rate. In 
either case, it will be necessary to have at least four and perhaps eight 
equivalent DOHSAT links connecting the TDRS ground station or the Data 
Handling Center to the next communication nodes. Design impacts to the Data 
Handling Center would be dependent upon which method for relay of data is 
selected. If the TDRSS ground station does not provide data buffering, the 
Data Handling Center must. Otherwise, the Data Handling Center impact is 
probably not substantially dependent on the transmission scenario selected. 

A trade study will be conducted in Task 3 to determine the program impact of 
using 1, 2, or 3 single access channels. 

5.4.2 Real Time Operation of Payloads. 

There is a requirement for customers to be able to operate their payloads 
interactively in real time from remote operations centers. Real-time 
operation implies the real time entry of commands, the real-time processing of 
those commands and delivery of the command to the payload, the real-time 
return of payload monitor data from the payload to the customer, and some 
amount of real-time processing of the payload monitor data to enable the 
customer to determine the next operation. Intermingling of the real-time data 
throughput with the bulk data discussed in Section 5.4.1 would create very 
serious operating problems. However, many of the payloads can be operated in 
real time using a dedicated or shared MA channel. Most payloads can be 
operated using only the data capabilities of a single SSA TDRS channel. 
Depending on the specific payloads, it may be possible to operate several 
payloads simultaneously on a single SSA channel, and some may be operated 
simultaneously on an MA channel. Since the SSA and MA channels can be kept 
separate from the KSA channel, this would facilitate real-time data movement 
for a single customer. It appears that the SSDS can provide for the real-time 
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operation needs of most customers in this manner. The allowable reaction time 
or performance delay for various payloads will also bear on this problem. 

MDAC will develop representative delays allowable. 

A second implication of real-time operation is involved in the designation of 
commands as being unrestricted, restricted, or constrained. Real-time 
operation must be conducted using only allowable commands. The Space Station 
and all of its payloads must be in operating modes that will permit all of the 
operations that are to be performed in real-time payload operation. This 
creates a potential for a severe scheduling problem for real-time payload 
operations. 

Real-time operation may also be conducted by a Space Station guest 
investigator or mission specialist onboard the Space Station. This mode of 
operation relieves the data communication problems between the Space Station 
and the customers facility. The operation may need to be supported by a 
two-way audio or video return and two-way audio link between the Space Station 
and the customer's facility. Including video return and frame rates in excess 
of those which can be transmitted by a TORS SSA band would again impose 
difficult data separation problems. Real-time operation on board will also 
require that all of the constraint and restriction checking for commands be 
accomplished on board. 

5.4.3 Automation 

The degree to which SSDS functions are automated will have a major impact on 
the design of the SSDS. Functions which can be automated can be located 
either on board or on the ground according to results of relatively simple 
trade studies. Functions which are not completely automated impose 
requirements on the operators. Since operators are a limited resource on 
board the Space Station, the opportunity for onboard manned involvement in the 
operation of the Space Station functions is limited. Therefore, functions 
which are not automated will tend to be driven to locations on the ground. 
There will certainly be effects on the Space Station engineering data rates. 
There may also be effects on the operation and performance of Space Station 
systems which are not fully automated. 
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5.4.4 Scheduling 


In the preceding paragraphs several references to scheduling problems have 
been raised. Automation of many of the scheduling functions appears to be 
important in reducing program operating costs. However, both operators and 
customers will require that they be allowed to interact the scheduling 
function. Scheduling appears to be driven toward a responsive, interactive 
tool. The concept developed for scheduling functions in Task 1 appears to be 
amenable to this form of schedule development. However, other alternatives 
should be considered in selecting the concept to be used in scheduling. Some 
of the requirements placing additional burdens on scheduling function include 

• Customer and operator interactive scheduling. 

• Flight crew involvement in selecting tasks to be performed on orbit 
and the sequence and timing of these tasks. 

• The customer requirement for rapid rescheduling to meet "windows of 
opportunity" for his payload. 

• The desire of many customers for real-time payload operation, which 
involves the real-time processing of commands through the scheduling 
function and the rapid arbitration of restricted or constrained 
commands not executable in the current schedule. 

• The major impact on day-to-day schedules caused by the scheduling of 
major events such as satellite servicing, vehicle mating and 
launching, and major maintenance for buildup activities on the Space 
Station or payloads. 

These requirements all drive scheduling toward a high degree of automation. 

The degree of difficulty embodied in automating scheduling will be very 
strongly affected by the degree to which the systems resources are to be 
optimized. Scheduling a function to 80% of a limiting or constraining 
capacity is far easier than scheduling a function to 90% or 100% of that 
capacity. Scheduling automation will be greatly facilitated by working to the 
80% capacity level for all but the most critical functions. The three 
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resources identified as most critical are: Space Station power. Space Station 

crew time, and communications data rate. Communications data rates are 
buffered by onboard storage of data. Power generation is buffered by onboard 
energy storage. Limiting of payloads and their duty cycles, especially during 
the early years of Space Station operation, to something significantly less 
than the limits of these constraining resources will greatly simplify the 
automation of Space Station program scheduling. Hence, there is a trade 
between the cost and time required to develop varying degrees of schedule 
automation with varying degrees of sophistication and the ability to fully 
utilize limiting Space Station resources. However, automated scheduling is 
mandatory to meet Space Station customer requirements. 

5.4.5 Level of Physical Distribution 

The SSDS functions will be physically distributed among many geographic and 
space locations. Some locations will be divided into two or more facilities. 
Within facilities, functions may be allocated to multiple processors and 
storage units. 

The level of distribution, including both the numbers of locations and 
facilities and the functions assigned to the locations and facilities, and 
the types and quantities of data traffic among functions will drive the 
selection of network concepts to be used. The problems of distribution and 
networking must be worked together to produce the optimum system design. 

Distribution, and the associated potential for functional autonomy, can also 
benefit SSDS development and maintenance. Functional partitioning with well 
selected interfaces allows corrections, extensions, and upgrades to be 
incorporated in one function substantially independent of other functions. 

This capability will be required in the development and anticipated growth and 
evolution of the Space Station. Functional distribution should be planned to 
facilitate system developmental and operational autonomy, as it affects this 
flexibility. 

These benefits must be traded against the inherent design problems of highly 
distributed systems, e.g., data base management, resource control, and network 
communications. 
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5.5 REQUIREMENTS TRACEABILITY 


The credibility of SSIS functions evolved by the Task 1 activities is 
maintained by full traceability to the requirement that each function was 
derived to meet. The need to understand the system drivers is the first of 
three major benefits that traceability provides. By having traceability 
between the top level requirements and the functions, changes in requirements 
are made simpler. If the design of a system to implement a function is found 
to be too complex or expensive, the driving requirement may be traced and 
altered. Any alterations to a requirement may also affett other functions. 
With a traceability system the affected functions can be traced and modified 
as required. 

Requirement/function traceability supports function justification. With a 
traceability system each function can be traced to its key driving 
requirement, thus each function is justified. 

The visibility of the completeness of the functions list is also provided by 
assuring traceability. Mapping all the SSDS related requirements insures that 
the functions list accommodates all requirements, thus the functions list is 
validated and checked for completeness. 

5.5.1 Requirement Sources 

The Space Station Definition and Preliminary Design RFP (Reference 1), and the 
Customer Requirements for Standard Services from the SSIS (Reference 2) are 
the primary control documents for use in the traceability matrix. 

Additionally, engineering analyses were performed on the data base derived by 
the Langley Mission Requirements Working Group (reference 3) to extract 
mission requirements that affect the SSDS. 

5.5.2 Traceability Implementation 

An analysis of the requirements documents was performed to extract the 
functional requirements that pertained to the SSDS. After this analysis was 
completed, each of the resulting requirements were mapped to specific 
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functions that were derived to meet each requirement. The results from the 
mapping process were entered into a computerized traceability matrix that was 
developed using the ACCENT R data management system. 

The automated traceability matrix provides complete top down/bottom up 
traceability. A requirement can be traced to the functions that satisfy the 
requirement. In addition, functions can be traced to the requirements that 
gave rise to each function; thus, the traceability matrix gives complete 
top-down/bottom-up traceability as shown in Figure 5-9. 


Additional bottom-up traceability exists within the requirements data base. 

Many functions were derived from other requirements documents such as Yellow 
Books and COG briefing material (before References 1 and 2 were available). 

To accommodate this, space was provided on a functional data sheet to give the 
document name and paragraph number of the requirement that needed the function. 
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5.5.3 Traceability Report Examples 

The top-down traceability report maps each requirement to the function derived 
to meet the requirement. The requirement is identified by its unique 
requirement number, document abbreviation from where the requirement was 
extracted, and the paragraph number of the requirement. Each requirement is 
also given a brief descriptor to help further identify the requirement. 
Requirements extracted from Reference 3 are identified by the major mission 
number, then the count of other missions that need the function is given in 
parentheses. Next, the list of functions that map to the requirement are 
given. The functions are identified by their derived function number and 
abbreviated function title. Example output from the top-down report can be 
seen in Figure 5-10. The full report is in Appendix A-5. 

The bottom-up traceability report maps each function to the requirements that 
gave rise to the function. The function is identified by function number and 
abbreviated function title. The requirements are identified by their 
paragraph number from the document from which they were extracted. The 
document can be identified from the requirement number field. Requirements 
numbered from 1000-1999 come from Reference 1, requirements numbered from 
2000-2999 come from Reference 2, and requirements numbered from 3000-3999 come 
from the analysis of Reference 3. The requirement is further identified by a 
brief descriptor. Example output from the report can be seen in Figure 5-11. 
The complete bottom-up report is in Appendix A-6. 
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REQUIREMENT i 

DOCUMENT 

PARAGRAPH # 


1105 

RFP 

C -4-2. 2. 8 


DESCRIPTOR 

ATTITUOE CTRL & 

VELOCITY 

ADJUSTMENT 


OERIVED FUNCTION 

NUMBER 

FUNCTION 

TITLE 

4.1.2 

4.1.3 


GUIDANCE 

ATTITUDE 

CONTROL 


REQUIREMENT # 

DOCUMENT 

PARAGRAPH # 

2012 

CRSS 

3.2.2 

DESCRIPTOR 

PROVIDE CUSTOMER 

DATA ACCOUNTABILITY 

DERIVED FUNCTION 

NUMBER 

FUNCTION TITLE 

1 .4.6 


CUSTOMER DATA ACCOUNTING 

2.1 


VALIOATE P/L CMMDS/DATA 

2.2 


CHECK P/L CMMDS/DATA 

3.3 


DEVELOP OP EVENT SCHEDULE 


REQUIREMENT # 

DOCUMENT 

PARAGRAPH # 

3023 

MRWG 

SA/\X0303(8) 

DESCRIPTOR 



CREW PHYSIOLOGICAL MONITORING 


DERIVED FUNCTION 

NUMBER 

FUNCTION TITLE 


4.3.1 HEALTH MAINTENANCE 


Figure 5-10. Output from Top-Down Traceability Report 
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FUNCTION NUMBER 

2.5.2 


FUNCTION NAME 
COST P/L OPS 


PARAGRAPH 

NUMBER REQ £ DESCRIPTOR 

C -2-3.1 .3 1005 INDEPENDENT CUST. OPERATION & MONITOR OF P/L 

C -3-3.1 .G 1034 INDEPENDENT CUST. OPERATION AND MONITOR 

6. 3. 1.1 2046 ACTIVATE STORED COMMAND SEQUENCES 

6.3.2 2047 STORED P/L CMMD ACTIVATED BY ANOTHER STORED CMMD 

7.1.3 2053 PAYLOAD HOUSEKEEPING DATA MONITOR 

SAAX0305(32) 3040 CUSTOMER PROCESS CONTROL 

C0MM1 117(37) 3044 PAYLOAD ACTIVATION/SAFING 

Figure 5-1 1. Output from Bottom-Up Traceability Report 
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Section 6 

Substantiating Analyses/Technical Justification 


This section contains a description of additional analyses which were 
performed in the development of the SSDS and SSIS functional requirements. 

The section also contains the technical justification for some of the key 
performance requi rements . This section is not intended to be a complete 
discourse on the analyses undertaken. Rather, it is a supplement to the other 
sections of this report wherein many of the appropriate analyses are described. 

6.1 REVIEW OF ANALYSES PERFORMED 


The methodology followed in developing the SSDS and SSIS requirements was 
described in Section 3 of this report. Three parallel paths were followed in 
developing the SSIS and SSDS requirements. One path involved the review of 
then available literature and extraction from the literature functions which 
were appropriate for the SSIS and SSDS. A second path used structured systems 
analysis to define the logical steps required to process data during 
end-to-end movement through the system. The third path used requirements from 
the Mission Requirements Working Group, the Space Station Phase 8 RFP, and the 
customer's requirements for standard services from the SSIS, produced by 
GSFC. Functional and performance requirements were identified from these 
three documents and traced through to the SSIS functional requirements and the 
SSDS requirements. 

The structured systems analysis was described at a top level in section 4.3. 
Section 6.2 will present the Level 1 data flow. diagrams and the analyses 
represented in the indicated flows. Lower level data flow diagrams and the 
accompanying data dictionary will be developed as a part of task 4. 

The development of the function requirements was covered in Section 5.1. The 
analysis of available literature and development of SSIS and SSDS functions is 
shown in Appendix A-4. 
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Section 6.3 shows the development of functional requirements from the mission 
requirements working group output. Section 6.4 shows a compilation of 
performance requirements as generated by the Mission Requirements Working 
Group. 

6.2 STRUCTURED SYSTEMS ANALYSIS - LEVEL 1 DATA FLOW DIAGRAMS 

There are two accepted approaches in structured systems analysis to developing 
Level 1 data flow diagrams from a level 0 data flow diagram. In one approach 
the level 1 data flow diagram covers the entire system, but contains 
significantly more detail than the level 0 diagram. In the other approach 
each function in the level 0 diagram is expanded at Level 1. Because of the 
complexity of the system and the significant degree of independence of 
functions at level 0, the latter course has been chosen. 

The Level 0 data flow diagram was shown as Figure 4-3. This diagram is 
reproduced here as Figure 6-1 for convenience. The diagram contains seven 
functions, each of which will be expanded as Level 1 data flow diagrams. 

Figure 6-2 shows the expansion of Function 1, Manage Customer/Operator 
Delivered Data. This function receives data generated by the payloads and 
core systems and delivers the data to its appropriate destination. The 
external agency in the upper left hand corner of the diagram, labelled OMV, 
OTV, and constellation interfaces represents the communication interfaces on 
the Space Station to elements in the constellation. These elements may be 
transferring to the Space Station both data to be relayed to a destination in 
real time and data which may be held for bulk transfer at a frequency of 
approximately once per orbit. Real-time data are delivered to Function 1.1, 
Manage Real-Time Return. Bulk data are delivered to a data store labeled 
"Delayed Payload Data." Similarly core systems, at the top of the figure, 
also generate real-time data for monitoring. The bulk core systems data to be 
returned has previously been stored by the core system functions in a data 
store labeled Core Status. The real time core system data are also delivered 
to Function 1.1. At the far left, Space Station payload data to be delivered 
in real time are routed to Function 1.1 while delayable payload data are 
routed to a data store, and held for the once per orbit bulk data return. 
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The onboard customer or operator represents one of the end points of the 
data. Both real-time and delayed data are shown as delivered to the onboard 
customer/operator. Note that the box representing this external agency has 
been duplicated and it appears at the top center and the bottom left of the 
figure. The onboard customer or operator use these data to monitor the 
performance of payloads and to interact with payloads or core systems in real 
time. A two-way voice and video communication link between the onboard 
customer or operator and the ground customer or operator is provided by this 
function. 


Bulk data from both the core and the payloads is delivered to Function 1.2, 
Manage Delayed Data Return. Both data return links are governed by previously 
established priorities. Both deliver data to a data distribution function, 
Function 1.3. The data distribution function will read the data header, 
select the appropriate routing of the data, and deliver the data to the 
designated end point. The data are shown as divided into two streams. One 
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Figure 6-2. SSDS Level 1 OFO 1.0 Manage Customer/Operator Delivered Data 

stream includes all customer data while the other stream includes all core 
data. The recipients are the ground customers at their own facilities, 
customers regional data centers, the engineering data center, and ground 
operators. The customer payload data will be delivered either to the 
customer's own facility or to the customer's regional data facility, depending 
upon the customer's selection. Core data are either delivered to ground 
operators or to the core data center for archiving. 


Host of the customer's ancillary data requirements are expected to be met by 
delivering ancillary data in real time to the customer's payload on the Space 
Station. Additional ancillary data are provided either from the Space Station 
control center or the engineering data center upon customer request. 

Figure 6-3 shows the management of customer or operator supplied data. This 
function manages the commands and data supplied by the customer or by the core 
system operator. Payload commands and data are received from the 
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customer/operator in the upper right hand corner of the figure while core 
commands are received from the core operator at the right center of the 
figure. Commands and data destined for the payload or for vehicles in the 
constellation are sent to function 2.1, Validate Payload Commands/Data . In 
this function the customer or operator is first authenticated as being one who 
is able to enter commands. The address of the command is then checked against 
those that the customer or operator is authorized to command. 

The commands and data meeting these tests are termed valid payload data and 
valid payload commands. Valid payload data are delivered directly to the 
payloads or to the OMV, OTV, or constellation interface with no further 
checking. Valid payload commands are checked against the list of constrained 
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and restricted commands contained in the command dictionary. Those commmands 
found to be unrestricted are delivered directly to the constellation interface 
or payload. Those found to be restricted or constrained are sent to Function 
3.3 to determine whether the command can be executed. A command log is kept 
to record the disposition of all commands. Disposition is reported back to 
the operator who entered the command. 

Commands and data entered by the core system operator follow a similar chain 
of processes. The commands are validated in Function 2.3. However, valid 
core commands are all checked for restriction in Function 3.3. As with the 
payloads, valid core data are sent directly to the appropriate core system. 

Ancillary data required by payloads and by constellation elements is provided 
through Function 2.4. Function 2.5 provides support for the operation of 
customer systems, including the operation of customer payloads, the provision 
of data processing resources in support of customer payload operation, the 
operation of the OMV and the OTV, and support of customer payload checkout. 

Function 2.6, SSPE Checkout/Service, which would normally appear at this 
level, is not included because the data flow paths are many and varied. It 
was felt that their inclusion would not significantly improve understanding of 
the system operation. 

Function 3.0, Schedule and Execute Operations is shown in the Figure 6-4. The 
scheduling of Space Station operations begins with a master plan generated by 
the TMIS. This input is seen in the center left hand side of the figure. The 
master plan contains major events such as the STS visits to the Space Station, 
OMV and OTV launches, major maintenance actions and buildup of the Space 
Station, addition and removal of payloads, major construction activities, and 
major payload maintenance actions. The accommodation portion of the master 
plan shows what payloads will be onboard the Space Station at what times and 
the characteristics of the payload operations. 

Typical day schedules are developed for both a normal day and for days on 
which major events occur. Normal days are defined as those days when no major 
events take place. These days are expected to comprise approximately 60% to 
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Figure 6*4. SSDS Level 1 DFD 3.0 Schedule and Execute Operations 


80% of the total operating days of the Space Station. A normal day schedule 
is used as a baseline for developing a schedule for a major event day. 

Payload operation may be discontinued on major event days in accordance with 
constraints imposed by the major event taking place and with any limitations 
that may be required for critical Space Station resources. Operating 
priorities are used to allocate any impacted Space Station resources. 

Customers and operators input their desired operations with sufficient 
descriptive information to develop timelines, assess impacts on Space Station 
resources, and determine interferences between operations of core and payload 
systems. Any conflicts in the schedule are examined in the scheduling 
function and possible resolution is reported back to the customers and 
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operators. Again, operating priorities are used to arbitrate between 
competing requirements for critical resources and interferences or conflicts 
between the operation and characteristics of the payloads and core systems. 

Shuttle manifests and schedules have previously been established in the master 
plan. Additional interaction is allowed to provide space on the Shuttle for 
repair parts and resupply of consumables. A file of recurring operations is 
kept to show resource requirements timelines and interferences for each of the 
recurring core and payload operations. This file is periodically updated by 
the information coming into the development of typical day schedules or the 
development of short term schedules. 

Short term schedules are developed beginning with a baseline of a normal day 
or a major event day. The events in the normal operating day are confirmed 
with the customers and operators. Any change requests from the customers or 
operators are entered into the short term schedule. Resource availability and 
utilization, interferences, and possible resolutions of conflicts are relayed 
back to the customers and operators. The customers and operators 
interactively develop the short term schedule to optimize the output of 
payloads during specific days. 

Communications needs are arbitrated with network control for each individual 
day. Communication allocations are returned from the network control showing 
the time slots that can be reserved for the major communication links to be 
used. 

The flight crew is involved in the development of the short term schedule 
through their task selections. Again, conflicts are resolved by operating 
priorities. 

The output of the short term schedule is held in the data store. The short 
term schedule will typically be developed, beginning approximately one week 
before the date of operation. The schedule may be updated or revised to 
accommodate targets of opportunity by individual customers. 
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The operating event schedule is the actual detailed timeline on which the 
Space Station will operate for a particular day. Function 3.3 develops the 
operating event schedule based on the short term schedule for that day. The 
real-time commands for the payloads and for the core system are checked 
against the restrictions or constraints for those commands. Those commands 
which are found to be provided for within the short term scheduled are time 
tagged and loaded into the operating events schedule. Those restricted or 
constrained commands which are inconsistent with the short term schedule are 
returned to the short term schedule development function for arbitration 
between the customers and operators. 

Any change to the payload or core which has not been scheduled will 
automatically trigger a review of the operating events schedule to ensure that 
all of the commands that have been stored in that file are executable. 

The operations to be executed are selected from the operating events schedule 
in accordance with their time tag by the sequence operations function. 

Payload commands are sent on to the payloads on the constellation interfaces. 
Core commands are sent to Function 4, Operating Core Systems. The timing for 
the execution of the commands in the operating events schedule can be 
controlled to approximately 1 msec. The time input comes from Function 4.1.6, 
Time and Frequence Management. 

The commands stored in the operating events schedule are not envisioned to be 
the detailed instructions set that is executed by the payload or core system. 
These commands are envisioned to be keys that trigger the execution of a 
command sequence which has been prestored in the payload or the core system 
processor. 

The operation of the Space Station and ground core systems is shown in Figure 
6-5. The core systems are split into avionics core systems and non-avionics 
core systems, following approximately along the lines of predominantly 
software systems and predominantly hardware systems. Operator control inputs 
enter into the system via the validated core commands and sequence operations 
functions in the upper right hand corner. These commands have been previously 
checked for restrictions and constraints and are found to be executable at the 
time the commands are issued by these functions. 


251 



0201 

ij 

[non-gn g c 
CORE 
SYSTEMS 


N0N-6N G C 
OPERATING 
IfOMHANOS 


SENSOR 

DATA 


4.2 


OPERATE 
NON-GN S C 
CORE 
SYSTEMS 


RECONFIGURE. 

DISCONNECT 




NQN-6N G C STATUS J 


0011 


GN G C STATUS 


CORE STATUS 


MANAGE 

FLIGHT 

SYSTEM 

FACILITIES 


i n 



GN G C 

4.1 


OPERATING 


0202 

GN G C 
SYSTEM 

n COMMANOS 

OPERATE 
SN G C 
SYSTEM 

SENSOR 
DATA ^ 


. - 


CORE 

AVIONICS 

DATA 


AVIONICS 

SERVICES 

REQUESTS 


4.4 


PROVIDE 

CUSTOMER 

AVIONICS 

SERVICES 


. MASS. AREA PROPERTIES 


=\_ 


0203 i MASS PROPERTIES CONFIGURATION 


0016 


PAYLOAD STATUS 


PROPERTY 

UPDATES 


MEDICAL. 

TRAINING 

RECOROS 

t 


0204 CREM STATUS 




1 

2. 3/3. 4 T 



| 


0013 

PAYLOADS. 


EXEC. CORE, 
COMMANDS/ 1 
.£ATA i 

VALIDATE 
COflE CNHOS 
SEQUENCE 
OPERATIONS 

CONST. 

ELEMENTS 


! 



1 

it 




s 

t. 1/3.2 ' 



i 

1 

i 

i 

MN6 R.T. 

DATA/ 
DEV. S.T. 
SCHEDULES 



i 



4.3 


SUPPORT 

FLIGHT 

CREM 

[ACTIVITIES 


PAYLOAD STATUS 


FLIGHT CREM 
CREM TASK 
SELECTIONS 


Data 


MESSAGES. 
PROCEDURES. 
REQUIRED TASKS 


CORE DATA 


FACILITIES STATUS 


CREM DATA 
REQUESTS. 

TASK SELECTIONS 


0018 


FACILITIES STATUS 


Figure 6*5. SSDS Level 1 DFD 4.0 Operate Core Systems 



The two functions operate non-avionics core systems and operate avionic 
systems are still high level functions. There are two additional levels of 
subdivision, shown in Appendix A-4, before the detailed operation of these 
functions is defined. At the level illustrated, these functions enter 
commands and control into the systems and receive back sensor data. The 
sensor data are processed to provide the status of the core systems. Each of 
the functions must have both ground and onboard sections in order to provide 
for the autonomous operation of the Space Station onboard as well as the 
operation of the Space Station by ground crews during periods of emergency or 
periods when the Space Station is not inhabited. 

Function 5.1, Manage Flight System Facilities, monitors the voltage and 
current draw of the payloads as well as other potentially critical indicators 
of payload status. When a payload is determined to be drawing more power than 
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all ocateo to that payload or when evidence of serious payload malfunction is 
detected the reconfigure or disconnect command is sent to the non-avionics 
core systems. The function will then disconnect operating power from the 
payload which appears to be malfunctioning. 

Function 4.3 in the lower right hand corner, provides support for the flight 
crew activities. This function prepares the necessary displays of core data 
to the flight crew to enable them to monitor and operate the core systems. 

The function also displays procedures to the crew to instruct the crew in 
Space Station and payload operations and maintenance procedures. The function 
assists in displaying required tasks to the crew and entering their task 
selections into the scheduling function. 

Function 4.4 provides special avionics services to payloads and to customers. 
This function will provide such avionics type information as is not normally 
generated by the core avionics systems. This function includes such avionics 
services as providing pointing coordinates to payloads, determining and 
forecasting ground track and monitoring Space Station contamination 
environment. 

Function 4.5 provides a general monitor and statusing of both the core and the 
payload systems. This function monitors core payload facilities and crew 
status and prepares appropriate display data for operators and customers. 

This function also prepares the mass properties configuration data necessary 
for the avionics systems to determine orbit and attitude and propagate the 
navigation state vector. 

The management of SSOS facilities is illustrated in Figure 6-6. Each of the 
functions manages the data processing equipment in its facility. The 
functions include the evaluation of the data processing requirements for the 
facility and determination of the utilization of the available data processing 
equipment. The functions monitor the status of their respected facilities and 
determine facility capability. 

Function 5.2, Manage Space Station Control Center Facilities, also includes a 
global facilities management function. This function includes the 
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Figure 6-6. SSDS Level 1 DFD 5.0 Manage Facilities and Resources 

coordination of the configuration of data processing equipment for all 
facilities in order to provide for the prompt movement of data through the 
system. This function also arranges the network and TDRS satellite schedules. 

As previously mentioned, monitoring of payload status indicators and core 
system indicators in Function 5.1 may lead to a requirement to reconfigure the 
non-avionic core systems or to disconnect various payloads. This function 
also controls the systematic shedding of load under conditions of loss of 
power system capability in order to protect the Space Station and its crew. 

The development, simulation, integration, and training function operation is 
illustrated in Figure 6-7. This function provides a development and 
simulation environment for general purpose use by contractors, customers and 
system operators. NASA is considering multiple facilities to support this 
function, including a software development environment, core and payload 
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Figure 6*7. SSDS Level 1 DFD 6.0 Develop, Simulate, Integrate and Train 


integration facilities, and a Space Station simulator and training facility. 
This section discusses those SSDS functions performed by the aggregate of all 
of these facilities. The data flow diagram has five major branches: 

a. Communication simulation models which enable the function to 
interface with Space Station elements through communication 
interfaces . 

b. Hardware integration interfaces which enable the function to validate 
the performance of payload and contractor hardware for onsite and 
off-site. 

c. Software integration capability which allows the function to verify 
the functioning and operation of software packages in the simulated 
environment of the Space Station system. 
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d. Customer and operator training capability which conducts training 
exercises and simulates the response of the Space Station system to 
customer or operator input. 

e. Software development environment for both operational software and 
software simulations built into the simulation models. 

These five areas all allow cross coupling between areas to share capabilities 
among the simulations. A single function provides an operator interface to 
enter into each of the branches of the system. Function 6.1, Interpret Model 
Requests, provides a user friendly environment to assist the facility user in 
establishing the model requirements and developing the software simulation 
that will best suit the needs of the user. 

Each branch is separated into functions which develop the model configuration 
and functions which actually perform the simulation. Thus 6.2 develops 
communication model configurations while 6.3 simulates the Space Station 
communications elements. Function 6.3 interfaces with an external 
communications interface that allows any portion of the communication links of 
the Space Station system to be accessed in the simulation. Data are provided 
directly back to the user. It is anticipated that this branch will be used 
primarily in verifying the customer end-to-end data links. 

Function 6.4 develops the hardware integration configuration while Function 
6.5 simulates the Space Station elements, allowing both payload and Space 
Station hardware to be verified. The facilities include external interfaces 
for both customer payloads and contractor hardware to be validated on site. 

The communication interface can also be used to validate off-site hardware. 

The integration simulation model may also be exported to a customer or 
contractor off-site location to allow the customer or contractor to perform 
his own integration tests at his own facility. 

The software integration configuration is developed in Function 6.6. Function 
6.7 simulates the operation of the Space Station Program processors with their 
software. The customer operator or contractor inserts his software into the 
Simulation Models data store from the external agency box in the top center in 
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the figure. This model then is available to insert into the software 
simulation from the duplicated simulation data store in the right center of 
the figure. 

Function 6.10 supports the development of software for both simulation and use 
in operational equipment. Validated models may be transported directly to the 
Space Station or payloads through the communications interface provided in 
this function. 

Training exercises are configured in Function 6.8 and performed in Function 
6.9. The simulator prompts the operator to execute the training exercise, 
accepts the operator responses and displays back the system reaction to the 
operator response. Actual or simulated core data are made availabe to the 
simulation to support the use of authentic data in the simulations. 

The programmatic support is illustrated in Figure 6-8. It is envisioned that 
the majority of the programmatics for the Space Station program will be 
provided through the THIS. A limited logistics plan covering payload and 
station resupply and maintenance needs will be delivered to the THIS from the 
SSDS. Logistics support requirements are coordinated by the THIS. 

A majority of the manuals are also envisioned to be prepared by Space Station 
program contractors, and available through THIS. However, the actual 
operating procedures for various core systems are expected to be prepared and 
maintained in the SSDS. Payloads procedures for both operations and 
maintenance are also expected to be provided by the customer. The procedures 
in these manuals are expected to be made available to the customers and 
facility operators, primarily via CRT display. 

Inventory control is also limited to the inventories of material and equipment 
in the various SSDS facilities. The TMIS and SSDS will cooperate in this 
inventory control. 

Configuration management is predominantly a TMIS function. The only role of 
configuration management in the SSDS is to maintain the specific data required 
to operate and control the Space Station. 
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Figure 6’8. SSDS Level 1 DFD 7.0 Support Space Station Program 


Customers are expected to provide their own command authentication data. 
Customers, in addition to using the identification provided through the TMIS, 
may also incorporate such passwords as they wish to protect the transmission 
of data to and from their payloads. Customers are expected to provide a 
complete list of their commands including the restrictions and constraints on 
any commands. Those commands to be restricted or constrained are negotiated 
with the Space Station Program through the TMIS. The command dictionary will 
contain not only the complete list of commands and the commands that are 
constrained or restricted, but will also contain the circumstances under which 
these constrained or restricted commands are executable. 

The above data flow diagrams contain the logical structure required for the 
platforms, also. However, there are many non-platform functions, external 
agencies, and data flows also presented. Figures 6-9 through 6-11 show the 
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diagrams significantly altered for the platforms, i.e., Functions 1.0, 2.0 and 
4.0. The logic of each is the same as for the Space Station, with the 
exception of the elements removed. The remaining data flow diagrams are 
substantially the same and show replicated and common or shared functions. 



| 00 1 1 ; CORE STATUS 


Figure 6-9. SSDS Level 1 DFD — Platforms, 1.0 Manage Customer/Operator Delivered Data 


6.3 MRWG FUNCTIONAL REQUIREMENTS ANALYSIS 

the Mission Requirements Working Group (MRWG) of the Space Station task force 
prepared a mission model for the Space Station comprised of 111 missions. 
These requirements and the mission model were subsequently updated by the 
Woods Hole Mission Requirements Workshop. Requirements for Space Station 
program services for each of the missions were identified in the mission 
model. These requirements include power, thermal control, data processing, 
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data rate, data storage, crew activities, mass, and volume. There are well 
over 100 such requirements tabulated in the electronic data base maintained by 
Langley Research Center. In addition, there are textual descriptions of each 
mission and its operation. This data base was reviewed to determine the 
standard customer services being requested from the mission data base. 
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In this review, 57 standard customer services for the SSOS were identified. 
Thirty of the services involved the providing of data either already available 
in the core systems or readily providable by core systems software. 
Twenty-seven of these services require functions which are not presently 
envisioned to be required to operate the core systems. Customer core and 
service functions were developed for each of the missions in the MRWG mission 
model (111 missions). This tabulation has not been updated for the "Woods 
Hole" model, as the conclusions regarding SSOS mission support services would 
not be materially altered. These are recorded in Tables 6-1 thru 6-8. The 
missions are divided according to payloads in or on the Space Station, 
payloads on platforms, payload integration and launch services, and satellite 



Figure 6-11. SSDS Level 1 DFD — Platforms, 4.0 O ierate Core Systems 
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servicing missions. Tables 6-1 thru 6-4 show the standard core service 
functional requirements of the mission model. Tables 6-5 thru 6-8 show the 
payload requirements for customer services which are not normally provided by 
the core systems. 

Each of the functional requirements which were identified for the Space 
Station payloads has been recorded in the requirements traceability matrix. 

The requirements are also assigned to functions in the Space Station functions 
list and are incorporated into the SSDS functional requirements in section 5.3 
Table 6-1. Space Station Mission Requirements for Standard Core Services 
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Table 6-2. Platform Requirements for Standard Core Services 
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Table 6-3. Payload Integration Mission Requirements for Standard Core Services 
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Table 6-4. Free Flyer Servicing Mission Requirements for Standard Core Services 



6.4 MRWG PERFORMANCE REQUIREMENTS ANALYSIS 


The various panels at the Woods Hole Requirements Workshop tabulated 
performance requirements for each of the 111 missions in the mission set. 

These requirements include performance requirements applicable to the SSDS, 
such as: 

• Data rate from the payloads 

• Payload operating hours per cycle 

• Payload operating cycles per day 

• Delta delivery time 

• Command rate to the payloads 

• Command generation hours per cycle 

• Command generation cycles per day 

• Command delivery time 

• Voice channel time 

• Video channel time. 

In addition, an upper limit for onboard data storage for the Space Station and 
platforms can be inferred by assuming a once per orbit data dump to the 
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Table 6-5. Space Station Mission Requirements for Customer Services 



Y - MISSION REQUIRES THIS SERVICE 


CODE NO 
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DEPLOYMENT. ASSEMBLY AND CONSTRUCTION 
STRUCTURAL DYNAMICS 
DESIGN VERIFICATION TECHNOLOGY 
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ATTITUDE CONTROL TECHNOLOGY 
FIGURE CONTROL TECHNOLOGY 
ADVANCED CONTROL DEVICE TECHNOL 
TELEPRESENCE TECHNOLOGY 
INTERACTIVE HUMAN FACTORS 
ENVIRONMENTAL EFFECTS TECHNOL 
HABITATION TECHNOLOGY 
MEDICAL TECHNOLOGY 
OTV SERVICING TECHNOLOGY 


ground. These requirements are summarized for the Space Station and for the 
platforms in Tables 6-9 thru 6-13. The peak data rates shown in the tables 
represent the sum of the peak data rates of the individual payloads which are 
on board the vehicles for each of the years shown. Two average data rates are 
shown, one for all missions, and one excluding the very high rate missions 
likely to be downlinked by "bent-pipe" relay. The average data rates for the 
low rate missions Includes a scheduling factor of 1.8 for data rates less than 
50 Mbps to accommodate peak data recording rates. The peak and average command 
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Table 6*6. Platform Requirements for Customer Services 
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RAOAR ALTIMETER I ALT! 
SCATTEROMETER (SCATTI 
TROPOSPHERIC COMPOSITION MONITOR 
DIRECT TROPOSHPERIC WIND SENSING 
UPPER ATMOSPHERIC COMPOSITION 
UPPER ATMOSPHERIC WIND SOUNDING 
ENVIRONMENTAL MONITORS 
AUTOMATED DATA COLLECT. /LOC SYS 
STEREO SAR AND MLA AND CZCS 
MULTI LINEAR ARRAY STEREO 


YYYYYYYjY 
YYYYYYY Y 


YYYYYYYY 


Table 6-7. Payload Integration Mission Requirements for Customer Services 


Y MISSION REQUIRES THIS SERVICE 



km 


V /&/ 

mm 


LARGE DEPLOYABLE REFLECTOR 
MARS GEOSCIEN CLIMATOL ORBITER 
LUNAR GEOSCIENCES ORBITER 
COMET RENOEZVOUS/ASTEROID FLYBY 
VENUS ATMOSPHERE PROBE 
SATURN ORBITER/TITAN PROBE 
SATURN FLYBY SATURN PROBE 
MAIN BELT ASTEROID RENDEZVOUS 
NEAR EARTH ASTEROID RENDEZVOUS 
MARS SAMPLE RETURN LAUNCH 
LARGE MICROWAVE ANTENNA 
CLASS IV COMM SAT OELIVERY 
CLASS III SAT DELIVERY 
CLASS II COMM SAT DELIVERY 
CLASS I COMM SAT DELIVERY 
CLASS IV COMM SAT SERVICING 
CLASS III COMM SAT SERVICING 
CLASS II COMM SAT SERVICING 


SPACE BASEO OTV 
SATELLITE SERVICING 
MULTIUSE PLATFORM 
SATELLITE SERVICING TECH 
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Table 6-8. Free Flyer Servicing Mission Requirements for Customer Services 



Y - MISSION REQUIRES THIS SERVICE 


SAAX001 2 

HUBBLE SPACE TELESCOPE 


Y 


Y 







r 

Y 






Y 

Y 

Y 

Y 

Y 

Y 


Y 



SAAX0013 

GAMMA RAY OBSERVATORY 


Y 


Y 








Y 






Y 

Y 

Y 

Y 

Y 

Y 


Y 



SAAX0014 

X RAY TIMING EXPLORER 




Y 








Y 






Y 

Y 

Y 

Y 

Y 

Y 


Y 



SAAX001 5 

INTERNAT SOLAR TERRESTRIAL PROGRAM 




























SAAX0016 

SOLAR MAX MISSION 




Y 








Y 






Y 

Y 

Y 

Y 

Y 

Y 


Y 



SA AX 001 7 

ADVANCED X RAY ASTROPHYSICS FACILITY 




Y 








Y 






Y 

Y 

Y 

Y 

Y 

Y 


Y 



SAAX0018 

UV LONG BASELINE INTERFER 




Y 








Y 






Y 

Y 

Y 

Y 

Y 

Y 





SAAX0019 

FAR UV SPECTROSCOPY EXPLORER 




Y 








Y 






Y 

Y 

Y 

Y 

Y 

Y 





SAAX0022 

SOLAR SEISMOLOGY MISSION 




Y 








Y 






Y 

Y 

Y 

Y 

Y 

Y 





SAAX0203 

OCEAN TOPOGRAPHY EXP (TOPEXI 




























SAAX0204 

GEOPOTENTIAL RESEARCH MISSION 






| 






















SAAX0205 

GEOSYNCHRONOUS PLATFORM 

Y 





1 






















SA AX 0206 

UPPER ATMOSPHERE RESEARCH SAT 





! 























SAAX0222 

INFRARED SOUNDING 

Y 



1 

1 Y 


Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 




Y 

Y 

Y 

Y 

Y 

Y 





SAAX0223 

LARGE IMAGER 




I 



Y 







‘ 




Y 

Y 

Y 

Y 

Y 

Y 





SAAX0402 

MICROG VARIABLE G' FREE FLYER 







Y 











Y 

Y 

Y 

Y 

Y 

Y 





SAAX0501 

EXPERIMENTAL GEO PLATFORM (XGP) 




1 

i 








| 


Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 






Table 6-9. Space Station Attached and Internal Payloads Mission Data Requirements Summary 



1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

2001 

Peak Data Rate 
(Mbps) 

2.4 

2.4 

312 

312 

403 

403 

353 

353 

53 

53 

Scheduled Data 

Rate, Low Rate^ 
Missions (Mbps) 
(Ref 15) 

4.3 

4.3 


7.1 

52.9 

54.1 

39.4 

39.4 

39.4 

39.4 

Average Data 
Rate 1 2 3 (Mbps) 

2.4 

2.4 

6.3 

6.4 

55.0 

55.7 

38.1 

38.1 

35.6 

35.6 

Onboard Data 
Storage (Gbits) 

13 

13 

34 

35 

297 

301 

206 

206 

192 

192 

Peak Command 
Rate (kbps) 

79 

78 

79 

82 

81 

77 

67 

67 

67 

67 

Average Command 
Rate (kbps) 

1.6 

1.6 

2.8 

3.3 

3.4 

3.4 

3.0 

3.5 

3.5 

3.5 

Voice/Video Channel 
Time (hr/day) 

19.4 

21.1 

45.8 

47.6 

71.6 

71.3 

71.3 

71.4 

71.4 

71.4 


1. Contains Missions With Data Ratas Less Than 200 Mbps, Uses a 1.8 Schedule Factor lor Missions 
With Data Rates Below SO Mbps 

2. Rate for All Missions Without 1.8 Schedule Factor Applies to Long Term Averages 

3. Based on Storage at Scheduled Oata Rate for the Low Data Rate Missions for One Orbit 
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Table 6-10. Coorbiting Platform Mission Data 

Requirements Summary 




1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

2001 

Peak Data Rate 
(Mbps) 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Scheduled Data 
Rate (Ref 15) 
(Mbps) 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Avg Data Rate 
(Mbps) 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Onboard 
Storage (Gbits) 

5.4 

5.4 

5.4 

5.4 

5.4 

5.4 

5.4 

5.4 

5.4 

5.4 

Peak Command 
Rate (kbps) 

10 

10 

10 

10 

10 

10 

10 

10 

10 

10 

Average Command 0.625 1 * 0.625 0.625 0.625 0.625 

Rate (kbps) 

1. Based on Space Station Relay of All COP Data Once per Orbit 

0.625 

0.625 

0.625 

0.625 

0.625 


Table 6-11. Polar Platform 1 Mission Data Requirements Summary 



1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

2001 

Peak Data Rata 
(Mbps) 

393 

393 

393 

393 

395 

395 

393 

669 

669 

669 

Scheduled Data 1 
Rate, Low Rate 
Missions (Mbps) 
(Ref 15) 

28.4 

28.4 

28.4 

28.4 

30.7 

30.7 

28.4 

28.4 

28.4 

28.4 

Average Data 
Rate 2 (Mbps) 

79.6 

79.6 

79.6 

79.6 

80.9 

80.9 

79.6 

154.4 

154.4 

154.4 

Onboard Storage 
(Gbits) 3 

347 

347 

347 

347 

353 

353 

347 

450 

450 

450 

Peak Command 
Rate (kbps) 

4.6 

4.6 

4.6 

4.6 

24.6 

24.6 

4.6 

5.6 

5.6 

5.6 

Average Command 
Rate (kbps) 

0.05 

0.05 

0.05 

0.05 

0.21 

0.21 

0.05 

0.05 

0.05 

0.05 


1. Contains Missions With Data Ratas Lass Than 200 Mbps, Uses a 1.8 Schedule Factor for Missions 
Below 50 Mbps 

2. Rate for Missions Without 1.8 Schedule Factor 

3. Assumes Bent Pipe Relay of Missions Over 200 Mbps, Except Exclusion Zone, Twice per Orbit 
Downlink of Remainder 


data rates to the payloads are the sum of the command rates to each individual 
payload. Voice and live TV channel time also represent the summation of 
requirements for individual payloads on the Space Station. 


An aggregate allocation for voice, video, and core data is required to 
complete the downlink data rates. MDAC has used an allocation based on the 
following assumptions: 

• An initial combined voice/video allocation is made to the Space 

Station and payloads providing one high rate channel of video at 25 


268 


Table 6*12. Polar Platform 2 Mission Data Requirements Summary 



1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

2001 

Peak Data Rate 
(Mbps) 

300 

300 

302 

302 

302 

302 

302 

302 

302 

302 

Scheduled Data 1 
Rate, Low Rate 
Missions (Mbps) 
(Ref IS) 

0.1 

0.1 

3.8 

3.8 

3.8 

3.8 

3.8 

3.8 

3.8 

3.8 

Average Data 
Rate 2 (Mbps) 

16.3 

16.3 

18.3 

18.3 

18.3 

18.3 

18.3 

18.3 

18.3 

18.3 

Onboard Storage 
(Gbits) 

108.2 

108.2 

118.3 

118.3 

118.3 

118.3 

118.3 

118.3 

118.3 

118.3 

Peak Command 
Rate (kbps) 

6.1 

6.1 

10.1 

10.1 

10.1 

10.1 

10.1 

10.1 

10.1 

10.1 

Average Command 
Rate (kbps) 

0.36 

0.36 

0.41 

0.41 

0.41 

0.41 

0.41 

0.41 

0.41 

0.41 


1. Contains Missions With Data Ratas Lass Than 200 Mbps, lisas a 1.8 Schadula Factor for Missions 
Below 50 Mbps 

2. Rata for Missions Without 1.8 Schadula Factor 

3. Assumes Bent Pipe Relay of Missions Over 200 Mbps, Except Exclusion Zone, IWice per Orbit 
Downlink of Remainder 


Table 6-13. Polar Platform 3 Mission Data Requirements Summary 


1992 

1993 1994 1995 1996 

1997 

1998 

1999 

2000 

2001 

Peak Data Rata 
(Mbps) 

0.043 

0.043 

0.043 

76 

76 

76 

Scheduled Data 1 
Rate, Low Rate 
Missions (Mbps) 
(Ref 15) 

0.034 

0.034 

0.034 

41.2 

41.2 

41.2 

Average Data 
Rate 2 (Mbps) 

0.019 

0.019 

0.019 

41.2 

41.2 

41.2 

Onboard Storage 
(Gbits) 3 

0.09 

0.09 

0.09 

103 

103 

103 

Peak Command 
Rate (kbps) 

3 

3 

3 

4 

4 

4 

Average Command 
Rate (kbps) 

0.02 

0.02 

0.02 

0.03 

0.03 

0.03 


1. Contains Missions With Data Rates Lass Than 200 Mbps, Uses a 1.8 Schedule Factor for Missions 
Below 50 Mbps 

2. Rate for Missions Without 1.8 Schedule Factor 

3. Assumes Bant Pipe Relay of Missions Over 200 Mbps, Except Exclusion Zone, IWice per Orbit 
Downlink of Remainder 
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Mbps for 6 hours per day and one low rate channel at 1.544 Mbps 
continuously. Since most payload and surveillance requirements can 
use freeze frame. It Is assumed that all of the sources can be 
multiplexed Into a single low rate channel. 

• Two additional low rate channels are assumed for the growth Space 
Station, beginning in 1996. 

• Space Station core data are assumed to be 160 Kbps for bulk downlink. 
An allocation of 16 Kbps is provided for real time downlink under 
normal operation. 

• Platforms are assumed to have freeze frame surveillance video in a 150 
Kbps allocation. Note that data are taken continuously, and may be 

monitored by an expert system which can automatically increase the 

data rate to full band width in the event of a sudden change in the 

region surveyed. 

• Platforms are allocated an additional 50 Kbps for core data. 

The combined audio, video and core data rates are 8.55 Mbps through 1995 and 
10.30 from 1996 on. These values may be refined by later analyses, but will 
be used in this report to provide an allocation for data beyond payload 
digital data. 

The aggregate ground data handling requirements for the Data Handling Center 
(DHC) are developed in Table 6-14, assuming that a single center will handle 
data for the Space Station COP and POP. The average data rates from each 

facility, as given in Reference 1, are shown at the top of the table. The 

scheduling factor of 1.8 applied to the averages is used to size the onboard 
storage, but tends to be levelized during the transmission and data handling 
steps. Therefore, the DHC rates have been redeveloped to use actual 
instrument averages with the 1.8 scheduling factor removed. The average DHC 
rates range from 32 Mbps at IOC to a peak of 242 Mbps in 1995. 

There are few storage duration requirements given in Reference 2: 


1) Online storage of customer data for 12 hours. 


Table 6-14. SSIS/SSDS Data Handling Rates and Storage Capacities 



1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

2001 

SS Data Rata 
(Avg) 

Z4 

2.4 

6.3 

6.4 

55.0 

55.7 

38.1 

38.1 

35.6 

35.6 

COP Data Rata 
(Avg) 

1.0 

1.0 

1.0 

1.0 

1.0 

1.0 

1.0 

1.0 

1.0 

1.0 

POP1 

79.6 

79.6 

79.6 

79.6 

82.9 

82.9 

79.6 

154.4 

154.4 

154.4 

POP 2 Data Rata 

(Avg) 

16.3 

16.3 

18.3 

18.3 

18.3 

18.3 

18.3 

18.3 

18.3 

18.3 

POP3 

— 

— 

— 

— 

0.02 

0.02 0.02 

41.2 

41.2 

41.2 

Audio, Video and 
Core Data 
Allocation (Mbps) 

8.6 

8.6 

8.6 

8.6 

10.3 

10.3 

10.3 

10.3 

10.3 

10.3 

Combined Long- 
Term Average 
Data Rate 
SS + COP + 
POP 1, 2, 3 
(Mbps) 

108 

108 

114 

114 

166 

166 

147 

263 

261 

261 

12-Hour On-Line 
Storage Capacity 

(10 12 bits) 

4.7 

4.7 

4.9 

4.9 

7.2 

7.2 

6.4 

11.4 

11.3 

11.3 

1-wMk Short-Term 
Archive Capacity 

(10 12 bits) 

65 

65 

69 

69 

100 

100 

89 

159 

158 

158 

2-year Long-Term 
Archive Capacity 

6.8 

6.8 

7.2 

7.2 

10.4 

10.4 

9.3 

16.6 

16.4 

16.4 

(10 1 ® bits) 

— 










2) Rapid 

recal 1 

storage for 

up to 

one 

week. 

pending 

verification 

Of 


receipt of each data set by the customer. 


3) Short term archival storage maintained for one week after 
verification of acceptable data quality by the customer. 

4) Long term archiving for up to 2 years. 


There is a potential for the short term archive to be open ended In duration. 
If the data quality check by the customer is Immediate, durations 2 and 3 are 
the same. Table 6-14 Indicates the total storage requirements for customer 
data storage capacity to meet each of these three storage requirements. 
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Reference 13 Indicates that the science requirements for the two high rate 
Instruments on the POP (HRIS and SAR) may be met with a lower average data 
rate than Indicated In Table 6-14. It will therefore be assumed that: 

1) The equivalent of a single TORS KSA channel can support the combined 
bulk data transmission requirements of the Space Station, COP, and 
POP. 

2) The transmissions can be scheduled such that no simultaneous 
transmission Is required. 
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Section 7 
TASK MAINTENANCE 


The functional and performance requirements for the SSIS and the SSDS are 
based on mission definitions, customer requirements, operational requirements, 
and system configuration plans and assumptions. These requirements, plans, 
and assumptions are continually evolving as the total Space Station program 
moves forward. As part of the ongoing SSDS Analysis/Architecture Study the 
requirements defined in this study will be updated to reflect overall program 
evolution as well as reflect inputs from government reviews and to meet 
specific requirements definition needs of later tasks in the study contract. 

A specific study task (Task 6) has been defined to manage the maintenance of 
this requirements task product and other study products. 

The management of requirements updating will be facilitated by our electronic 
data base system. Requirement changes can be entered at a terminal and will 
be immediately available to NASA and to the study team by electronic access 
means. This ability to easily modify the requirements set must be tempered by 
the need to keep the requirements relatively stable during the critical phases 
of other study tasks, such as the system definition tasks. 

Our plans for managing and implementing requirements updates is to (1) 
accumulate a list of external changes and customer comments that potentially 
cause changes to the SSDS requirements, (2) assess each of these changes and 
comments for impact and timeliness, (3) coordinate the need for a requirements 
change and its timing with the NASA Technical Officer, (4) develop the revised 
requirements, and (5) update the requirements data base. Requirements data 
base changes will be made in blocks to provide a degree of stability. As a 
minimum, major requirements updates will be included in the study iterations 
that are planned for month 19 and month 24 of the study. It is anticipated 
that several earlier requirements updates will be made to support the trade 
study and system definition tasks. 
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Section 8 

CONCLUSIONS AND RECOMMENDATIONS 

Conclusions resulting from the Task 1 analyses and generation of SSIS/SSDS 
requirements include: 

1) An end-to-end, overall SSIS concept has been defined. This concept 

includes identification of all SSIS elements and their 

interrelationship. The major SSIS elements are: 

• Orbital elements interfacing with the Space Station for 
communications, traffic control and on orbit servicing (COP, 
Free-Flyers) 

• Orbital elements sharing ground facilities and services (POP, 
high altitude COP) 

• Space Station core systems and payloads 

• Communications links (TDRSS, DOMSAT, other satellite and ground 
links, DSN, Network Control) 

• Data handling and distribution elements 

• Customer support elements providing POCC, archival and data 
processing services 

• Customer facilities 

• Space Station ground elements (Space Station Control Center, 
platform control centers, other vehicle control centers, Space 
Station archives, and development, integration, and training 
elements) . 
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2) Clear boundaries were defined for the SSDS and the SSIS. These 
boundaries were codified in a set of criteria that will allow 
continued, consistent evaluation at lower levels. The boundaries 
identify elements in the SSIS, and divide SSIS functions among SSDS, 
THIS, and SSIS Standard Customer Services. Principal boundary 
elements interfacing with the SSDS include: 

• Customers interface with the SSDS at a point(s) where data are 
delivered to the customer's designated end point as raw data 
with level 0 processing and where commands and data are entered 
by the customer 

• Payload physical interfaces generally coincide with their SSDS 
interfaces. Exceptions may exist where the SSDS provides on 
orbit data processing support for the payloads 

• Space Station core systems interface at the sensors and 
effectors, or at embedded, dedicated subsystem processors 

• Hultiprogram or institutional services, such as TDRSS, may 
interface with either the SSDS or the SSIS 

• Services in the SSIS, such as data archiving and customer data 
processing support, as well as THIS interface with the SSOS to 
transfer information 

3) The functioning of the SSIS was defined through Structured Systems 
Analysis. Hajor end-to-end data paths for command management and 
customer data delivery were defined in more detail. 

4) SSIS operating concepts were defined for both the total life cycle of 
customer involvement, and for the tasks performed by ground and 
onboard operations. 


276 



5) The team was able to develop a complete set of SSIS and SSOS 

functional requirements. The functional requirements are adequate to 

support Tasks 2 through 5. 

6) The primary SSDS design drivers identified are: 

• Aggregate average data rates for the Space Station, COP and POP 
and their payloads approach 300 Mbps. It will be difficult to 
schedule transmissions using only one TDRSS KSA channel at a 
time. In addition, ground data handling and relay facilities 
must be designed to meet a nearly continuous 300 Mbps data rate. 

• There are at least four points where data storage amounts and 
rates will drive system design: 

onboard storage on the Space Station ( O.SxlO 12 bits) and 
POP ( 10 12 bits) 

-I q 

online, 12 hour storage on the ground ( 10 bits) 
short term (1 week) archival storage (10 14 to 10 15 bits) 
two year archival storage ( 10 16 bits). 

• The total video requirements of 54 hours per day peak in 1996 
will tax the communications channels. Frame rates should be 
minimized, and expert systems utilized to compress the video to 
a single equivalent, part time channel. 

• System transparency and user friendliness for customers will 
drive some design concepts and most customer interfaces with the 
system. 

• Planning and scheduling is a major design driver for all 
multiple customer systems. The scheduling function must be 
automated to the degree that customers and onboard crew may 
interactively develop schedules. 

• Development, integration, and training is also a major design 
driver. The Space Station will grow and evolve throughout its 
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indefinite lifetime, and new customers and payloads will join 
the program. The Space Station and customers will require 
continuing support for software development, hardware and 
software integration, system test, and training for both ground 
and onboard operators. 

• The level of physical distribution of functions, both geographic 
and local, will drive the selection of networking concepts. 
Physical distribution must be designed to enhance developmental 
and operational autonomy, especially to facilitate the 
anticipated Space Station growth and evolution. 

• Processing and interpreting payload data, while not an SSDS 
function, will require a major expansion of current capability. 

Recommendations from Task 1 include: 

1) Structured system analysis has proved to be a very useful tool for 
developing system concepts and functions. This approach should 
continue to be used for the design of the SSDS preliminary. 

2) The concepts from Task 1 should be presented to potential Space 
Station customers for comment and feedback. 

3) The Mission Requirements data base should be extended and refined to 
provide more definitive requirements, such as: 

• Live TV frame rates 

• Remote, real-time, interactive operating time 

• Ancillary data requirements 

• Data delivery time, performance, and form requirements. 

4) A special emphasis study is needed to identify and characterize 
customer classes and to develop operating concepts and requirements 
for each customer class. 
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DICTIONARY OF ACRONYMS AND TERMS 


CMS Customer Mission Specialist 

COP Co-orbiting Platform 

CPU Central Processor Unit 

DFD Oata Flow Diagram 

DHC Data Handling Center 

DMS Data Management System (see Definition) 

DSN Deep Space Network 

ECLSS Environmental Control and Life Support System 

EMU Extravehicular Mobility Unit (Space Suit) 

EVA Extravehicular Activity 

GPS Global Positioning System 

GSE Ground Support Equipment (used especially here to refer to 

integration test support) 

ICD Interface Control Document 

IOC Initial Operating Capability 

IVA Intravehicular Activity 

KSA Ku-band, Single Access 

MA Multiple Access (S-band) 

MDAC McDonnell Douglas Astronautics Company 

MMU Manned Maneuvering Unit 

MPAC Multipurpose Applications Console 

MRWG Mission Requirements Working Group 

NSTS National Space Transportation System 

OMV Orbital Maneuvering Vehicle (formerly TMS) 

ORU Orbital Replaceable Unit 

OTV Orbit Transfer Vehicle 

POCC Payload Operations Control Center 

POP Polar Orbiting Platform 

RDC Regional Data Center 

RMS Remote Manipulator System 

R/T Real-Time 

SDE Software Development Environment 

SPC Stored Program Commands 

SS Space Station 

SSA S-band, Single Access 

SSCC Space Station Control Center 

SSDS Space Station Data System 

SSIS Space Station Information System 

SSP Space Station Program 

SSPE Space Station Program Element 

TDAS Tracking and Data Acquisition Satellite 

TORS Tracking and Data Relay Satellite 

TDRSS Tracking and Data Relay Satellite System 

TMIS Technical and Management Information System 
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DEFINITIONS 


Level 0 Data Processing - Raw data with reconstructed sensor formats, time 
ordering, full resolution, and ancillary data. 

Level 1A Data Processing - Reversibly calibrated in physical units (level 0 
can be reconstructed). 

Level IB Data Processing - Irreversibly calibrated in physical units. 

Constellation - Spacecraft in the same orbit and within communications range 
of the Space Station. 

Core - That portion of the Space Station system which maintains the 
environment in which the customer operates. 

Customer - Individual/organization with Space Station payload responsibility; 
cradle to grave. 

Data Management System (DMS) - Onboard system that provides the processing, 
storage, and handling of digital data. 

Function - A single duty which is implemented, controlled, sensed, computed, 
monitored, or aided by electronic devices. 

Operator - NASA or contractor personnel who manage, coordinate and affect 
Space Station program operations and assist customers in accomplishing mission 
objectives. 

User - Any person or organization who requires the transitory use of the 

services provided by the Space Station and who is authorized to use those 
services. 

Data Privacy - Limited access to information to some level short of a complete 
guarantee of security. 

Security - The protection of resources from damages and the protection of data 
against accidental or intentional disclosure to unauthorized persons or 
unauthorized modification or destruction. 
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